Thanks for the response Malcolm- comments/follow-up inline below. > > 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.
Ok, do you know of any examples of how to setup/use the transaction management facilities? (This is stretching my experience with dbs, so am looking for some examples to see how it's put together.) > > 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. > Sorry, didn't mean my question that way... am well aware that they're both fine products. My (simplistic) understanding is that MySql is faster, and Postgresql has more advanced transaction/constraint/stored procedure capabilities, and as such, was wondering if that meant there was more (advanced?) transaction support if a postgresql backend were used. BTW- thanks for the good summary of how to select a db (saves me writing something similar for our co-ops ;-) )- in our case, we want more advanced data integrity, and speed is not (as yet) an issue. We're currently using MySql, but am toying with trying Postgresql... another reason why we'd like a mature db-layer to help shield us from these decisions :-). Thanks again! Julian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
