Re: Add optional FOR UPDATE clause to QuerySets
On 27 mai, 01:17, Sebastian Noack <[EMAIL PROTECTED]> wrote: [snip] > Even if it is done by many parallel connections, because of > transactions are managed by the DBMS too and ensure atomicity, > consistency, isolation and durability of each transaction > [snip] The problem is that DBMS don't use the same default isolation level. Many DBMS use a read committed default, some a repeatable read and very few a serializable level. Some DBMS are even unable to support serializable. The "for update" clause generally implied a repeatable read. Read committed allow another transaction to update a record previously read by your transaction. Repeatable read allow phantom which mean that if you redo a select new records can appear. For more information on isoloation level you can read http://en.wikipedia.org/wiki/Isolation_(computer_science) JF --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Django port on OpenVMS - Oracle/Rdb backend
On 2 mai, 10:55, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Jean-François wrote: > > My question was not really specific to any database backend (aggree > > that probably all database system, including Rdb can start a > > transaction implicitly, inclugind Rdb). But as I have noticed that a > > method start_transaction_sql() exist I have expect that this method > > was used. > > It is. But it used in only one place: when Django creates a script with > DDL operators for database creation. I can even guess the reason for it. > Historically Django was wrapping all "ALTER TABLE"s in a single BEGIN; > .. COMMIT; block. Contrary to common disbelief It works as expected in > PostgreSQL. In MySQL it doesn't work but also doesn't do any harm. And > when Oracle backend came by I think it was failing on this thing. This > is why Oracle is the only backend that overrides start_transaction_sql() > to make it an empty string instead of 'BEGIN;'. > Ok I understand, if I remember correctly Oracle, like MySQL and many others databases autocommit DDL operations. > > So to not commit, even a read only transaction, may introduced hand > > in a multi-processes architecture. > > Ah... Got it. But it's not a problem in Django because each connection > is closed altogether and thus rollbacked at the end of each request. Oops... I haven't thought to trace connect/disconnect operation to the database only commit/rollback. Now, I have a better understanding of the underlaying model. I suspect that open a database connection then closing it for each request may be a fairly expensive operation on most database systems, but I have no bench for this. Many thanks for your help. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Django port on OpenVMS - Oracle/Rdb backend
Ivan, Thanks for our reply. On 2 mai, 09:53, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Hello! I'll try to answer as much as I can. > > Jean-François wrote: > > - can Django run in a cluster environnement (OpenVMS has a "shared > > everything" cluster design) , meaning running simultaneous Django > > server on different systems, so in different processes, or it is > > mandatory to run in a one-process/multi-threads environment. > > It's not mandatory and not even recommended. A most common model for > running Django is multi-process. What made you think otherwise, BTW? > I have seem system which do such assumption, for example to implement a shared cache between thread or some thread only locking mechanism. Since my initial post, I have read chapter 20 of the django book and it look like a multi-process/multi-system can be deploy, very nice. I have to look at specific problem in a shared everything instead sharead nothing architecture, but nothing difficult to solve (or to do). > > - I have noticed that some database access are done without call to > > the database operations start_transaction_sql() , so use an implicit > > database start transaction. Is it a bug? > > I'd say it's like that for all cases, not some. AFAIK most databases > start transactions implicitly anyway. And though I didn't use an Oracle > backend myself I can judge by other people using it that it works good > too. So in practice it's not a bug. > > Anyway in your backend you can issue any starting statements for a > connection in the overridden cursor() method. > My question was not really specific to any database backend (aggree that probably all database system, including Rdb can start a transaction implicitly, inclugind Rdb). But as I have noticed that a method start_transaction_sql() exist I have expect that this method was used. to explicitly open transaction (it is generally a good design practice design to explicitly open and commit/rollback transaction). So it was just to report which may be a unwanted behavior. > > - Also transactions which do no change are not commited, it seem that > > it's feature but IMHO it's a bug. Some database systems execute select > > statement in a transaction context > > You mean that a database can be configured to run something > automatically on each connect? If yes then the fact that Django doesn't > account for this situation may be considered a bug, yes. However I'd say > that doing specific server-side things that require a client to react is > not a good design. If something should be done upon opening and before > closing a connection it's better done on Django side completely. A > custom database backend gives you an API for this. > Sorry I wasn't clear. Most databases execute select inside a transaction which implement an isolation level. The most common are read commited/repeatable read/serializable. For example if you run 2 differents sessions on you database: using a table foo with one column c and one integer row in the table with a value of 1 session A session B select * from foo; display the line select * from foo; display the line update foo set c=2 where c=1; hang until session A commit or rollback This is expected behaviour on most databases system if you use a repeatable read or serializable isolation level. So to not commit, even a read only transaction, may introduced hand in a multi-processes architecture. > > - date field parameter use timestamp format instead of date format for > > example use '2008-01-01 00:00:00' instead of '2008-01-01' and integer > > parameter sometimes use string instead of int. > > And about this I don't know anything, sorry! Thanks again. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Django port on OpenVMS - Oracle/Rdb backend
Any comment, especially on the transaction model? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Django port on OpenVMS - Oracle/Rdb backend
Hello, I have successfully port Django to OpenVMS and have start to build an Oracle/Rdb (http://www.oracle.com/rdb) backend. A few questions: - can Django run in a cluster environnement (OpenVMS has a "shared everything" cluster design) , meaning running simultaneous Django server on different systems, so in different processes, or it is mandatory to run in a one-process/multi-threads environment. - I have noticed that some database access are done without call to the database operations start_transaction_sql() , so use an implicit database start transaction. Is it a bug? - Also transactions which do no change are not commited, it seem that it's feature but IMHO it's a bug. Some database systems execute select statement in a transaction context and may lock record to maintain consistency (depend on the isolation level setting) until you commit or rollback the transaction. I would be nice to have, at the end of the http request an commit to be sure to close the transaction and release any outstanding locks. - date field parameter use timestamp format instead of date format for example use '2008-01-01 00:00:00' instead of '2008-01-01' and integer parameter sometimes use string instead of int. Is it a feature or a bug? Tanks for any informations, Jean-François --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
