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