Dependency problem in flatpages...
Now that the magic has been removed, and Django released 0.95, I decided to
start porting my applications over. I knew the merge of magic-removal was
coming, so I never deployed the apps. So, I decided to dump the tables that I
had (there was no useful information in them) and start over. Well, my project
had the following in the settings file:
INSTALLED_APPS = (
'django.contrib.*',
'www.apps.blog',
'www.apps.jobs',
)
When running 'django-admin.py syncdb', it was failing with the following error:
Creating table django_flatpage
Creating many-to-many tables for FlatPage model
Traceback (most recent call last):
File "/Users/jszakmeister/projects/django/django/bin/django-admin.py", line
5, in
management.execute_from_command_line()
File "/Users/jszakmeister/projects/django/django/core/management.py", line
1251, in execute_from_command_line
action_mapping[action]()
File "/Users/jszakmeister/projects/django/django/core/management.py", line
485, in syncdb
cursor.execute(statement)
File "/Users/jszakmeister/projects/django/django/db/backends/util.py", line
12, in execute
return self.cursor.execute(sql, params)
psycopg.ProgrammingError: ERROR: relation "django_site" does not exist
CREATE TABLE "django_flatpage_sites" (
"id" serial NOT NULL PRIMARY KEY,
"flatpage_id" integer NOT NULL REFERENCES "django_flatpage" ("id"),
"site_id" integer NOT NULL REFERENCES "django_site" ("id"),
UNIQUE ("flatpage_id", "site_id")
);
The problem is that the tables for django.contrib.sites aren't created before
the flatpages tables. I made a simple change to the settings file to include
the sites app before the others, so it was an easy fix.
The reason I bring it up at all is that if were going to allow a wildcard, it
seems reasonable to expect that interdependencies are going to be worked out,
and the tables will be created in the right order. Otherwise, the wildcard
loses some of it's appeal. Is there a simple way to extract the dependencies
on other apps models, before the tables are created? If so, I can take a stab
at fixing syncdb to Do The Right Thing. If not, is it suffucient to leave
things as they are, or should the wildcard import be removed completely?
Thanks!
-John
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Dependency problem in flatpages...
On Thu, 2006-08-10 at 05:55 -0400, John Szakmeister wrote: > Now that the magic has been removed, and Django released 0.95, I decided to > start porting my applications over. I knew the merge of magic-removal was > coming, so I never deployed the apps. So, I decided to dump the tables that > I had (there was no useful information in them) and start over. Well, my > project had the following in the settings file: > INSTALLED_APPS = ( > 'django.contrib.*', > 'www.apps.blog', > 'www.apps.jobs', > ) [...] > The problem is that the tables for django.contrib.sites aren't created > before the flatpages tables. I made a simple change to the settings > file to include the sites app before the others, so it was an easy > fix. > > The reason I bring it up at all is that if were going to allow a > wildcard, it seems reasonable to expect that interdependencies are > going to be worked out, and the tables will be created in the right > order. Otherwise, the wildcard loses some of it's appeal. Is there a > simple way to extract the dependencies on other apps models, before > the tables are created? If so, I can take a stab at fixing syncdb to > Do The Right Thing. Have a poke around in django/core/management.py in the _get_sql_model_create() function and see if you can work out why we're getting this wrong. The fact that the generated SQL has a "...REFERENCES ..." clause on the problem line, rather than trying an "ALTER TABLE..." statement later (out of _get_sql_for_pending_references()) means that the code thinks that table has already been created. We try hard not to do that. So I suspect this is a silly bug somewhere and it might be easy to fix if you drop in a few print statements and have an already failing example. I didn't know we allowed wildcards there (although it makes sense that it would work, whether intended or not), but the output is close to correct, so it might easy enough to work out what is going wrong. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Dependency problem in flatpages...
- Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: [snip] > Have a poke around in django/core/management.py in the > _get_sql_model_create() function and see if you can work out why we're > getting this wrong. > > The fact that the generated SQL has a "...REFERENCES ..." clause on the > problem line, rather than trying an "ALTER TABLE..." statement later > (out of _get_sql_for_pending_references()) means that the code thinks > that table has already been created. We try hard not to do that. So I > suspect this is a silly bug somewhere and it might be easy to fix if you > drop in a few print statements and have an already failing example. > > I didn't know we allowed wildcards there (although it makes sense that > it would work, whether intended or not), but the output is close to > correct, so it might easy enough to work out what is going wrong. Thanks! I'll try and take a look this weekend and see if I can resolve this issue. -John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Dependency problem in flatpages...
- Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2006-08-10 at 05:55 -0400, John Szakmeister wrote: > > Now that the magic has been removed, and Django released 0.95, I > decided to start porting my applications over. I knew the merge of > magic-removal was coming, so I never deployed the apps. So, I decided > to dump the tables that I had (there was no useful information in > them) and start over. Well, my project had the following in the > settings file: > > INSTALLED_APPS = ( > > 'django.contrib.*', > > 'www.apps.blog', > > 'www.apps.jobs', > > ) > [...] > > The problem is that the tables for django.contrib.sites aren't > created > > before the flatpages tables. I made a simple change to the > settings > > file to include the sites app before the others, so it was an easy > > fix. > > > > The reason I bring it up at all is that if were going to allow a > > wildcard, it seems reasonable to expect that interdependencies are > > going to be worked out, and the tables will be created in the right > > order. Otherwise, the wildcard loses some of it's appeal. Is there > a > > simple way to extract the dependencies on other apps models, before > > the tables are created? If so, I can take a stab at fixing syncdb > to > > Do The Right Thing. > > Have a poke around in django/core/management.py in the > _get_sql_model_create() function and see if you can work out why > we're > getting this wrong. > > The fact that the generated SQL has a "...REFERENCES ..." clause on > the > problem line, rather than trying an "ALTER TABLE..." statement later > (out of _get_sql_for_pending_references()) means that the code thinks > that table has already been created. We try hard not to do that. So I > suspect this is a silly bug somewhere and it might be easy to fix if > you > drop in a few print statements and have an already failing example. Looks like the problem is in _get_many_to_many_sql_for_model(). Unfortunately, it doesn't check to see whether or not the table exists before generating a reference. Is there somewhere else where the models are ordered by dependency before creation? -John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Dependency problem in flatpages...
[snip] > Looks like the problem is in _get_many_to_many_sql_for_model(). > Unfortunately, it doesn't check to see whether or not the table exists > before generating a reference. Is there somewhere else where the > models are ordered by dependency before creation? Looking further, you're right it looks like we're not adding Sites as a pending reference for some reason. -John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Dependency problem in flatpages...
- Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: [snip] > Have a poke around in django/core/management.py in the > _get_sql_model_create() function and see if you can work out why we're > getting this wrong. > > The fact that the generated SQL has a "...REFERENCES ..." clause on the > problem line, rather than trying an "ALTER TABLE..." statement later > (out of _get_sql_for_pending_references()) means that the code thinks > that table has already been created. We try hard not to do that. So I > suspect this is a silly bug somewhere and it might be easy to fix if you > drop in a few print statements and have an already failing example. > > I didn't know we allowed wildcards there (although it makes sense that > it would work, whether intended or not), but the output is close to > correct, so it might easy enough to work out what is going wrong. I little more research has found a couple more things. First, many to many fields aren't stored in opts.fields. They're moved at construction time into opts.many_to_many, and _get_sql_model_create() doesn't do anything with those fields. The REFERENCES string is actually coming out of _get_many_to_many_sql_for_model(), which assumes that the necessary tables already exist. The fundamental issue is that the table being referenced doesn't reside in the same application. It's actually part of the contrib.sites application, and I don't see anything in the code trying to analyze the dependencies across applications. This actually sounds like something that's been discussed in the past, and was probably present pre-magic-removal, although I'm certain that initially populating the database used to work before. I'm not sure where to go next, short of analyzing dependencies across applications. And unfortunately, that's a much bigger issue than I have time to deal with. :-( -John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
