Re: Support for db declaration of "on cascade delete"?
Thanks - I'll try this out on a fresh DB. You're right that I'm running sqlall on an already populated database. I'll post back if it looks like there was a real bug here. Thanks again for all of your help, Greg Russell Keith-Magee wrote: > On 10/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>> However, you shouldn't be having any problems with foreign key >>> constraints. The model creation process should be able to identify and >>> avoid any problems with forward declared foreign key constraints. >> This is what I would guess, but is it possible that "sqlall" produces >> different output than is actually used by "syncdb" for single >> applications? > > Certainly possible at the moment (hence my refactoring attempts). For > example, up until recently, syncdb didn't produce indicies for tables. > If you look at the internals, syncdb doesn't use sqlall to add new > tables - it duplicates sqlall logic because of some deficiencies in > the existing install/sqlall implementation. However, syncdb/sqlall do > share some sub-components - m2m table generation, table > back-references, etc. > > As for your sqlall output - I suspect these results are a red herring > - is this the output you get after running sqlall on a clean databse, > or after you have run syncdb? > > If some (or all) of the tables already exist (e.g., you run syncdb, > then run sqlall), sqlall could be getting confused because it can't > differentiate between tables that already exist, and tables it thinks > it needs to create. > > If you have a completely clean database, and then run sqlall, the > models won't necessarily be created in the order you expect (because > of dictionary ordering), but the constraints should be added correctly > (inline if the table has already been created, post declared as an > ALTER if they haven't). > > However, if sqlall is producing this output on a clean database, then > you may have found a nasty bug. > >> Any help would be appreciated here - it would take some work for me to >> automate the process of generating custom SQL handlers for each of my >> models, but it would be very clean for me to add a step in our dev process >> to modify the output of "sqlall" and just use that. > > It's probably not as messy as you think. If hand cranking SQL > modifiers for each model is too much work, here's another approach - > you could add a handler that listens for the post_syncdb signal, and > emits alter statements programatically for each foreign key it finds > in the model. > > Look for any instance of 'management.py' in the django sources for > examples of what you can do on a post_syncdb trigger. As an example, > the automated addition of the superuser and the addition of > permissions are both stimulated by post_syncdb handler. > > Yours, > Russ Magee %-) > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Support for db declaration of "on cascade delete"?
Waylan Limberg wrote: >> Do any of you know if there's a way to tell Django to specify "on > cascade delete" for foreign key references, when it creates DB tables? > > I don't believe you can. However, you can use sql or sqlall [1] to > output the table creation sql to a file for editing. For example: > > manage.py sqlall myapp > myapp.sql I was looking at this, but: Does anyone know why "manage.py sqlall" rearranges the order of the table-creates from what's in the models? I can't find the reason for the new ordering; it looks kind of random, and it causes the table-creates to fail because of foreign key constraints. > > Then open myapp.sql in your favorite editor and alter the sql as you > see fit. After saving, feed that file into your db. > > [1]: > http://www.djangoproject.com/documentation/django_admin/#sql-appname-appname >> I'm developing an application that is mostly using Django to touch my >> DB, but that defines some SQL stored-procedures for manipulation of some >> of its data by other clients. I'd like the db-level "on cascade delete" >> defined for these cases. >> >> Thanks, >> Greg >> >> > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Support for db declaration of "on cascade delete"?
All, Do any of you know if there's a way to tell Django to specify "on cascade delete" for foreign key references, when it creates DB tables? I'm developing an application that is mostly using Django to touch my DB, but that defines some SQL stored-procedures for manipulation of some of its data by other clients. I'd like the db-level "on cascade delete" defined for these cases. Thanks, Greg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Re: Model-level DB cache
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 the MySQL shell, it isn't reflected by
getting a new QuerySet from the Django model.
- If, in the Python session, I call transaction.commit(), I get an
error saying that I'm not under transaction management.
- After calling transaction.commit() and getting that error, getting
a new QuerySet does reflect the new DB changes.
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 play?
Thanks again to everyone for all of your help - I was afraid that there
wouldn't be a workaround for this at all.
-Greg
Michael Radziej wrote:
> 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>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo: Foo 8>]
>>
>> {{ In MySQL shell }}
>> delete from foo_foo where id=8;
>> commit;
>> exit;
>>
>> {{ In same manage.py shell }}
> a
>> [< Foo: Foo 5>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo: Foo 8>]
> b = Foo.objects.all()
> b
>> [< Foo: Foo 5>, < Foo: Foo 6>, < Foo: Foo 7>, < Foo: Foo 8>]
> transaction.rollback()
>> Traceback (most recent call last):
>> File "", line 1, in ?
>> File "[...]/django/db/transaction.py", line 161, in rollback
>> set_clean()
>> File "[...]/django/db/transaction.py", line 102, in set_clean
>> raise TransactionManagementError("This code isn't under transaction
>> management")
>> TransactionManagementError: This code isn't under transaction
>> management
> b[3]
>> < Foo: Foo 8>
>> ==
>>
>> Maybe we're making the same mistake, but this behavior seems strange to
>> me as well.
>
> I made a transaction.commit(), got the same error, but then the
> Foo.objects.all() returned the new set. I'm not sure why I get
> the error, but the behaviour is normal for certain transaction
> isolation levels. You don't see the result of transcations that
> committed after the start of your current transation (for
> 'repeatable read' and 'serializable')
>
> You can have the same fun with two mysql sessions and without any
> django.
>
> Try this (you might need to set transaction level repeatable read
> to make it work):
>
>
> Session1: begin;
>select * from xyz
>
>
>Session2: delete from xyz;
>Session2: commit;
>
> Session1: select * from xyz
>
> This is a normal database thing an not mysql specific, but
> there's a long but fine article on
>
> http://dev.mysql.com/books/mysqlpress/mysql-tutorial/ch10.html
>
>
> Michael
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users
-~--~~~~--~~--~--~---
Re: Model-level DB cache
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 -- Django > saves the query results in the QuerySet's cache and returns the results > that have been explicitly requested (e.g., the next element, if the > QuerySet is being iterated over). *Subsequent evaluations of the > **QuerySet** reuse the cached results.* I did read that documentation, yeah. My understanding of what it said is that: x=SomeModel.objects.all() ...returns a QuerySet, x, which has a cache populated by the query's result at the time of request. What I'm seeing is that, once a QuerySet on this model is cached, then _any_ attempt to get a new QuerySet on this model returns the results cached by the first QuerySet. In other words, I would expect 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 >>> print len(x) # The table is empty, but x has cached values 2 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=SomeModel.objects.all() # This gets a new QuerySet into y >>> value = y[0] # Some operation to actually fill y's cache >>> print len(y) # The new QuerySet has the cached result from x! 2 It's the second that I'm seeing - with the result that I can't get at fresh data once any QuerySet in my process has fetched the data once. I know that it's a subtle distinction, but its effect is large. Let me know if I'm not being clear. Thanks, Greg > > Don > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
Model-level DB cache
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 can't clear. If I call "Model.objects.all()" and then make any changes to the DB with my MySQL client, the results of subsequent Model.objects.all() invocations never changes. Example, with model PendingAlert: PendingAlert.objects.all() [, ] (...now, in mysql...) mysql> delete from pending_alert; Query OK, 2 rows affected (0.00 sec) (...now, back in my Django session) PendingAlert.objects.all() [, ] ...I just verified - the first Django session never clears its cache even if I alter the pending_alert table using Django instead of straight in MySQL. Just to make sure that I have the right mental model here: Isn't Model.objects.all() supposed to create a QuerySet with its own search? Shouldn't these calls be touching the database directly? Any help would be appreciated here - thanks, Greg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~---
