On Tue, 2007-06-12 at 17:31 -0700, womble wrote: > Hi, > > in the past I've written to this list re using the django db back-end as > a db access layer for a test-automation system I work on; we hope to > re-write the current front-end with django at some point. > > We're a little closer to experimenting with this, and have another question: > is there any coherency checking/row (table?) locking implemented in > django's db layer? > > i.e. if I have two scripts, on two different machines, both accessing > the same db & table, what built in support is there to catch > race-conditions/invalid updates/etc?
You'll need to do manual transaction management, for a start, just like you would with any two processes from remote machines accessing the same data. The only point of coordination is the database, so you need to work through there. We don't do this by default, since it adds a lot of overhead when not needed. Also, I don't think we have the equivalent of "select for update" transaction locking at the moment (I may be wrong -- I have never had need to use the manual transaction management stuff beyond playing with it once to see what was possible), so you may need to write some extra code for Django to do that. Feel free to discuss any design issues on the django-developers list when you get to that point, since it would be useful to have. > Are there any examples out there > someone can point me to? Also, is there any difference with which db is > used- MySql vs Postgres? That's a "vi vs. emacs" or "red wine vs. white wine" discussion. Yes, unsurprisingly, there are differences. Do they matter to your particular case? Who knows! There are a lot of different comparisons on the web, some less biased than others. At the end of the day, though, there are lots of very high profile, high traffic sites using both types databases in production. If you are going to be at all close to any limits, the only way to have any confidence in your results is to do lots of benchmarking with common usage patterns and data sets. That sounds like a cop-out, but it's the truth: very few publically available database comparisons will use a data set and connection pattern that matches what you will need. Do be aware of anything more than a year or two old that compares either feature sets or performance, though. With the rate of development that occurs in both database groups, things move forwards all the time. There are, for example, a lot of "MySQL doesn't support XYZ" posts around that are from people stuck in 2002 or even earlier, back when MySQL's support for sub-selects or transactions wasn't as good as it is now. Similarly, PostgreSQL has improved in a number of areas where it was a bit behind MySQL. Short version: for almost all cases, you can use either and be happy. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
