Do you mean db_check->database_check? That seems to check permissions and what not (which now that I think about it, I didn't really take into account). But it doesn't seem to even be approaching the ability to ALTER a table dependant on a new model. Did I miss something here?
The two step process allows more flexibility. For one, the python database api doesn't really allow a satisfactory introspection of the current database, so it's not really possible (or at least it's very difficult) to see if, for instance, I changed Document.lead from a CharField to a TextField. Since you don't have the original model file to reference, you can't see if that's the case. But with using an intermediate file, the user can specify that the field needs to be updated. Also, if a user renames a class from, for instance Image to Media, how is the program supposed to know that? At best it can see if a new class has the same fields as an older class, which transition tries to do, but what if you also chang a field in this class? In general, having the code guess what you want, and then allowing you to alter it, seems best. On 8/30/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 8/30/05, Brant Harris <[EMAIL PROTECTED]> wrote: > > I now have a working solution to ticket #12. > > Your solution is very intriguing. There's already a "django-admin.py > updatedb", which is currently commented-out in > django/core/management.py and is only about 75% done. It's similar to > what you've done -- it outputs ALTER TABLE statements -- but it's not > a two-step process that requires transition files. What was your > reasoning for using transition files as opposed to making it a > one-step thing? > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com | chicagocrime.org >
