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
-~----------~----~----~----~------~----~------~--~---
