On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> russell, i've re-read your linked email (from 8/4/07), and i'm still
> totally lost as to what you're proposing. i'm reading of application
> and verification of an SQL-abstraction syntax:
>
> mutations = [
> AddColumn('Author', 'dateofbirth', models.DateField,
> initial_value=None),
> DeleteColumn('Author', 'age')
> ]
>
> combined with a signature list embedded in the Meta class in model.
> (btw, you said earlier that "in_the_model==bad".... ???)
It needs to be _somewhere_. Meta is one option, but there are better
options. I was suggesting Meta as a better location than where you
were/are putting the settings (i.e., on the attributes themselves).
However, out of the model entirely would be preferable (and is
entirely possible).
> which is ok and all, but there is nothing on how to actually generate
> these mutations, except for the suggestion of calling it "syncdb --hint"
> (instead of "sqlevolve" i presume). is it up to the user to write them?
> where is the actual introspection/generation bit?
Introspection isn't an essential part of what I was proposing, but it
certainly could be used in two places:
1) Validation of final state - that the final state of the table after
migration matches the model definition. The AddColumn/DeleteColumn
mutations know what modifications they will make to the model
signatures, and this can be used as a form of soft validation.
However, the ultimate validation is that the tables in the database
match expectation at the end of a migration process. This can't be
done without introspection.
2) Reconciliation of modifications that have been made outside the
Django framework - i.e., if you tweak the tables outside of Django,
the signature in the Evolution table won't match the actual database
state. As a result, there will be a need for an evolution step to
'update the Evolution table'. This absolutely requires introspection,
as the state of a model definition is irrelevant to the problem.
Introspection could also be used as a replacement for the tag-tracking
function of the Evolution table. However, the Evolution table is a
much easier development task, and I think there is some value in
keeping the migration process documented in the database.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
