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