On 9/28/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Django probably does start a transaction somewhere, I don't know.
> Try to trace your session and you'll see.
The way I read the spec for DB-API's connection.commit, all cursors
are implicitly under transactions.
".commit
Note
wasn't a DB cache issue in my case, just a bug in my model code.
The first run of unittest silently failed, and subsequent ones showed
the above stack trace.
Running stuff in the python interpreter helped find the problem.
I do a connection._rollback() at the start of my unittest now, as
insuranc
I have a similar problem, though I am using PostgreSQL 8.1.3).
I run a unittest that creates a bunch of records against the database,
all of it using django and the model API.
This runs fine the first time, but shows the following stack trace on
subsequent runs.
It seems to hit the problem at t
Greg Plesur schrieb:
> So that's a work-around that I can use, but...is it okay behavior? That
> seems pretty broken. Is it possible that Django's DB connection has
> auto-commit off, but explicitly calls COMMIT internally on save()
> operations when there's no Django-level transaction in pla
That does fix it - thanks Michael.
I just want to summarize what I'm seeing, though, in case it helps others:
- In no place, either in my MySQL shell or my Python Django session,
am I explicitly starting a transaction. Further, my MySQL shell has
auto_commit on.
- If I make a change in t
Hawkeye schrieb:
> I had the same reaction at first... "this has to be a transaction
> issue", but I decided to give it a try.
>
> I'm working from trunk, and here's what I did to recreate the problem:
>
> ==
> {{ In manage.py shell }}
a = Foo.objects.all()
a
> [< Foo: Foo 5>,
I had the same reaction at first... "this has to be a transaction
issue", but I decided to give it a try.
I'm working from trunk, and here's what I did to recreate the problem:
==
{{ In manage.py shell }}
>>> a = Foo.objects.all()
>>> a
[< Foo: Foo 5>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo
Thanks to everyone for the replies here.
Just to be clear: I don't think that this is a transactions issue. The
Django-side part of this problem doesn't have transactions enabled, and
the MySQL-side is just a direct transactionless operation on the DB that
can be seen immediately by other cl
Greg Plesur schrieb:
> Hi all,
>
> I'm a new subscriber to this list, and am having an issue that I'm
> hoping you can help me with (I also posted this as a trouble-ticket,
> because I'm not seeing any references to this issue anywhere and it
> seems buggy):
>
> It looks like my models are ca
Greg Plesur wrote:
> But I would _not_ expect to see this:
>>>> x=SomeModel.objects.all() # This gets a QuerySet into x
>>>> value = x[0] # Some operation to actually fill x's cache
>>>> print len(x) # Verify that there are some entries in the table
>2
>
>>>> y=SomeMode
Don,
Don Arbow wrote:
> Did you read this documentation, especially the last line of this paragraph?
>
> http://www.djangoproject.com/documentation/db_api/#id3
>
> In a newly created QuerySet, the cache is empty. The first time a
> QuerySet is evaluated -- and, hence, a database query happens
On Sep 26, 2006, at 6:06 PM, Greg Plesur wrote:Hi all,I'm a new subscriber to this list, and am having an issue that I'm hoping you can help me with (I also posted this as a trouble-ticket, because I'm not seeing any references to this issue anywhere and it seems buggy):It looks like my models are
Hi all,
I'm a new subscriber to this list, and am having an issue that I'm
hoping you can help me with (I also posted this as a trouble-ticket,
because I'm not seeing any references to this issue anywhere and it
seems buggy):
It looks like my models are caching their DB query in a way that I
13 matches
Mail list logo
