caching between successive calls to model.objects.all()?
lev...@gmail.com
Python 2.4.3 (#1, Jun 13 2006, 16:41:45)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from oui3.mon.models import User
>>> User.objects.all()
[<User: te...@user.org>, <User: root>, <User: test-wsx>]
(then, in another shell:)
mysql> update user set username='test-wsy' where username='test-wsx';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
(back in the first shell:)
>>> User.objects.all()
[<User: te...@user.org>, <User: root>, <User: test-wsx>]
and yes, mysql auto-commit is on.
i'm using the multi-db branch.
lev...@gmail.com
terms:
1. I call model.objects.all() in an interactive shell
2. I modify the db directly in a different shell
3. I call model.objects.all() in the first shell again, and it doesn't
pick up my changes.
what's going on? i'm sure that the changes are actually committed in
the db. should i post this in django-developers instead?
On Jun 29, 1:29 pm, "lev...@gmail.com" <lev...@gmail.com> wrote:
> $ ./oui3/manage.py shell
> Python 2.4.3 (#1, Jun 13 2006, 16:41:45)
> [GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)>>> from oui3.mon.models import User
> >>> User.objects.all()
>
> [<User: t...@user.org>, <User: root>, <User: test-wsx>]
>
> (then, in another shell:)
>
> mysql> update user set username='test-wsy' where username='test-wsx';
> Query OK, 1 row affected (0.00 sec)
> Rows matched: 1 Changed: 1 Warnings: 0
>
> (back in the first shell:)
>
> >>> User.objects.all()
>
> [<User: t...@user.org>, <User: root>, <User: test-wsx>]
Benjamin Slavin
You mention you are using the multi-db branch. Do you get this
behavior in trunk?
What happens if you update a user from within the Django management
shell? Does this result in a correct QuerySet from all()?
Are you under transaction management in the management shell? If so,
depending on the isolation level, this behavior may be expected.
I think we're going to need a bit more information before we can be of
assistance (unless someone's seen this before).
Also, Ben Ford has recently decided to wrestle with multi-db, and is
attempting to get his changes checked in... you may want to tune in to
the django-dev list to keep abreast of any updates on his progress and
code availability.
- Ben
Lawrence Wang
Hello.
You mention you are using the multi-db branch. Do you get this
behavior in trunk?
i haven't tried this yet because i require multi-db functionality, so it does me no good if it works in trunk :) but i understand the value of trying this for debugging, and i will if it comes down to it.
What happens if you update a user from within the Django management
shell? Does this result in a correct QuerySet from all()?
yes.
Are you under transaction management in the management shell? If so,
depending on the isolation level, this behavior may be expected.
tell me more about transaction management -- i don't believe i'm using any, because there's nothing in my settings.py that would seem to apply, but perhaps i've overlooked something trivial.
I think we're going to need a bit more information before we can be of
assistance (unless someone's seen this before).
Also, Ben Ford has recently decided to wrestle with multi-db, and is
attempting to get his changes checked in... you may want to tune in to
the django-dev list to keep abreast of any updates on his progress and
code availability.
thanks for the heads-up. i'm looking forward to multi-db getting more up-to-date.
Benjamin Slavin
> tell me more about transaction management -- i don't believe i'm using any,
> because there's nothing in my settings.py that would seem to apply, but
> perhaps i've overlooked something trivial.
You can read about it at [0]. You can read more about isolation
levels in MySQL at [1].
If you're using InnoDB, it defaults to repeatable-read, which I
imagine is what you're seeing.
Try this in your shell **between** accesses to User.objects.all():
>>> from django.db import transaction
>>> transaction.commit_unless_managed()
If this is a problem for you, you can always change the isolation
level, but that's a database issue.
> thanks for the heads-up. i'm looking forward to multi-db getting more
> up-to-date.
See #4747 at [2].
- Ben
[0] http://www.djangoproject.com/documentation/transactions/
[1] http://www.databasejournal.com/features/mysql/article.php/3393161
[2] http://code.djangoproject.com/ticket/4747
Lawrence Wang
On 7/2/07, Lawrence Wang <lev...@gmail.com> wrote:
> tell me more about transaction management -- i don't believe i'm using any,
> because there's nothing in my settings.py that would seem to apply, but
> perhaps i've overlooked something trivial.
You can read about it at [0]. You can read more about isolation
levels in MySQL at [1].
If you're using InnoDB, it defaults to repeatable-read, which I
imagine is what you're seeing.
Try this in your shell **between** accesses to User.objects.all():
>>> from django.db import transaction
>>> transaction.commit_unless_managed()
sweet, that did it. thanks!