Hey all...I promise, I'm not trying to start trouble, but has anyone
actually TESTED the "rename core database tables" DDL against anything?
Not just for syntax validity (which, as of right now, I know it fails
with SQLite), but also a comparison of post-migration DDL to "start
clean" DDL (ie, are they the same)? And with a website? There's going
to be data missing here.
I see several issues beyond the initial syntax error with SQLite I
mentioned in an earlier thread:
1) We add content_type_id to auth_permission in the change scripts as
NULLable, but it's NOT NULL in a clean install.
2) We're not adding relevant data when you add columns. Again, with
content_type_id, you've added it and a FK reference to
django_content_type(id) (at least in PostgreSQL, where FKs work), but
no update to match up the data. That column is NULLable and empty in a
migrated database. I'll have to poke about in the innards to see what
that breaks, but I expect something will.
3) We're not updating data in django_content_type that appears to need
updating. You mention the table name creation tempate change in the
upgrade notes, and describe the easy fix for user tables ("We'd
recommend setting db_table, because it's easier."), but flatpages and
comments also have tables, have data in django_content_type, and would
require users to change django code to set the 'db_table' attribute.
Best to update the data.
Example: in a "clean install" of MR:
sqlite> select * from django_content_type where app_label like 'comm%'
or app_label like 'flat%';
4|Comment|comments|comment
5|Free comment|comments|freecomment
6|flat page|flatpages|flatpage
in a migrated db:
sqlite> select * from django_content_type where app_label like 'comm%'
or app_label like 'flat%';
11|Comment|comments|comments
12|Free comment|comments|freecomments
13|Karma score|comments|karma
14|User flag|comments|userflags
15|Moderator deletion|comments|moderatordeletions
16|flat page|flatpages|flatpages
I'm not yet certain of the relevance of the fact that there are added
rows in that second query [obviously, other stuff is installed, so it
may be ok], but the major point is that the data in the tables that
match the "clean install" records is different; the model field still
contains the pluralization. Presumably, this needs to be updated.
Please note: I'll be happy to help with this; I'm not suggesting that
it's anyone's fault, or that it should be perfect before I see it.
Unfortunately, for today, I've got to scramble to figure out how to get
a demo project using MR, and my regular website (using trunk) to
coexist right now, b/c the migration isn't clean (so I can't update my
website), and they have to run on the same apache install tomorrow.
After I work that out, I'll be happy to dive in and take a look at the
migration script stuff.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
