On Mon, 2008-09-29 at 03:25 -0700, Richard Davies wrote:
[...]
> So, do we agree that it makes sense for me to take the current 3460
> patch and complete it in the manner which I described in
> http://groups.google.com/group/django-developers/msg/48500109ac5e514d
> ?
I'd be amazed (and fairly
I'm going to make one final post in this thread, since we didn't quite
reach a conclusion.
Malcolm Tredinnick wrote:
> As I mentioned to Collin at the code sprint in Portland, I think it'd be
> a good idea to make sure we expose the ability to turn on auto-commit,
> but I don't really like
On Sep 23, 2008, at 18:32, [EMAIL PROTECTED] wrote:
> Django's saving can trample data unintentionally, and indeed, we've
> seen this in production. Trampling data is an extremely hard to find
> problem since it amounts to a race condition. Since this could be
> easily avoided in several
On Tue, Sep 23, [EMAIL PROTECTED] wrote:
>
> > You completely missed my point that if there's some integrity or other
> > database error in the sequence of multiple updates or deletes (and when
> > Django does updates to multiple tables or deletes, it extracts the id
> > values first), we can
> I think that we
> should try to write a patch which a) makes 3460 a configuration option
> as suggested, and b) supports transactions on top of the autocommit
> connection when explicitly requested (3460 currently doesn't, so parts
> of the test suite currently fail when it is applied).
+1
> You completely missed my point that if there's some integrity or other
> database error in the sequence of multiple updates or deletes (and when
> Django does updates to multiple tables or deletes, it extracts the id
> values first), we can currently roll back to the start of the sequence
> and
Michael Radziej wrote:
> There is no way to agree about the "#3460 ticket", because the ticket does
> not really state what you want to solve, but how you want to change Django.
...
> Now, please, pick only one pain
I certainly agree that we've been all over the place on this thread!
And my
On Mon, 2008-09-22 at 07:11 -0700, [EMAIL PROTECTED] wrote:
[...]
I've snipped the explanation of serialization levels. That's known
stuff. It's also pretty much irrelevant to this discussion, but since
you insist, I've addressed why the current behaviour is also a valid
possibility, below.
On Mon, Sep 22, Richard Davies wrote:
>
> > Can we figure out what this thread is about, and stick to it, please?
>
> As the person who originally started the thread ;-)
>
> I'd like to agree a design for a patch which will be accepted into
> Django trunk and will enable us to close the #3460
> Can we figure out what this thread is about, and stick to it, please?
As the person who originally started the thread ;-)
I'd like to agree a design for a patch which will be accepted into
Django trunk and will enable us to close the #3460 ticket.
The current #3460 patch needs more work.
On Mon, Sep 22, 2008 at 9:11 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> However, Django also misuses transactions in other cases (exactly the
> ones you mention). A transaction does not guarantee consistency of
> multiple operations, at least not in the default READ COMMITTED
>
> I've done a quick non-scientific test. Here's the code:
> ...
> So the default level is indeed faster but I have to confess I'm a lousy
> tester so I encourage anybody to conduct their own experiment.
I appreciate the test case here. Note that we were in the millions of
queries a day before
On Mon, Sep 22, [EMAIL PROTECTED] wrote:
> Django with #3460 is _significantly_ faster when the query load is
> high. If I ran stock Django on Chesspark, the database overhead would
> cripple the site.
I'd really like to see a kind of benchmark that I can try out to check your
measurements.
A
> It will also leave things vulnerable to having only some of your objects
> updated, some of them deleted, some of them saved with no way to restore
> to a known state. This proposed change is a bit more complicated than
> the patches in #3460, since it's kind of a good thing to preserve
>
> When it comes to overhead... As far as I know PostgreSQL in autocommit
> mode will wrap each statement (even SELECT) in an implicit transaction.
So what? Should we wrap it in 5 more just for giggles? Each one adds
overhead.
> > While you may think that you are not using transactions for
> I don't want to get into the argument about ticket 3460 itself but I
> just don't get this paragraph... What is special in web applications
> that makes them not require transactions? And more, how transactions --
> a mechanism for preventing DB to end up in an inconsistent state -- can
> get
Richard Davies wrote:
> That's an interesting article, and I follow your logic. However,
> Jack's original patch follows from profiling work he did on his
> Chesspark site (see
> http://metajack.wordpress.com/2007/07/25/do-you-know-what-your-database-is-doing/
> ) in which he claimed a 2-3x
Ivan Sagalaev wrote:
> When it comes to overhead... As far as I know PostgreSQL in autocommit
> mode will wrap each statement (even SELECT) in an implicit transaction.
>
> http://it.toolbox.com/blogs/database-soup/postgresql-application-performance-tips-part-1-13172
...
> So what Django does now
Malcolm Tredinnick wrote:
> As I mentioned to Collin at the code sprint in Portland, I think it'd be
> a good idea to make sure we expose the ability to turn on auto-commit,
> but I don't really like making it the default. In any case, providing
> the ability that's can be controlled via, for
On Sun, 2008-09-21 at 11:32 -0700, Richard Davies wrote:
[...]
> I suspect that this will significantly simplify the Django codebase
> vs.
> trying to simulate both auto-commit and transaction behaviors on top
> of a transactional connection - it would certainly remove most of the
> mechanisms
Richard Davies wrote:
> On the first question, I'd suspect that many pages of many (simple)
> web applications just have a one-to-one mapping between the web page
> and a single line of SQL on a normalized database - e.g. a page
> listing all events (single SELECT), a page listing all people at
> > It is also highly inefficient for Web applications (since
> > they most often do nothing transactional) and gets you into trouble in
> > error cases.
>
> I don't want to get into the argument about ticket 3460 itself but I
> just don't get this paragraph... What is special in web applications
> One reason not to do this is that it simply isn't standard behaviour for
> Python database adaptors (they must be in non-autocommit mode
> initially). So there's a principle of least-surprise thing going on.
I'm not convinced by the argument of least-surprise. As you said,
there
are explicit
[EMAIL PROTECTED] wrote:
> It is also highly inefficient for Web applications (since
> they most often do nothing transactional) and gets you into trouble in
> error cases.
I don't want to get into the argument about ticket 3460 itself but I
just don't get this paragraph... What is special in
> I believe this boils down to the same issue as ticket [3460] - both
> the psycopg1 and psycopg2 backends are using the wrong isolation
> level, as a result of which the Django SQL is wrapped by psycopg
> inside an implicit transaction. I have tried using the [3460] patch,
> which gives me the
On Fri, 2008-09-19 at 23:47 -0700, Richard Davies wrote:
> Hi Jacob,
>
> I agree that this is documented behavior for PostgreSQL
> _transactions_.
>
> The reason that I think it's a bug is that I shouldn't be in a
> transaction at all - as I understand
>
Hi Jacob,
I agree that this is documented behavior for PostgreSQL
_transactions_.
The reason that I think it's a bug is that I shouldn't be in a
transaction at all - as I understand
http://docs.djangoproject.com/en/dev/topics/db/transactions/
, the default behaviour should be auto-commit in
This is related to http://code.djangoproject.com/ticket/3460
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
Hi Richard --
What you've described is documented behavior for PostgreSQL (try
googling for "commands ignored until end of transaction block") --
Postgres does not alow *any* commands in a transaction after a
database error; you have to commit or rollback first.
Jacob
Hi all,
I believe that I have found a bug in Django 1.0 for both Postgresql
backends, but would very much appreciate your thoughts in case I am
misunderstanding something... The test case seems clear enough that
this must have been noticed before, and there is an existing open
ticket and patch
30 matches
Mail list logo
