On Jul 20, 2013, at 11:41 AM, David Szotten <[email protected]> wrote:
> south currently uses state freezing (which aways felt messy), but i believe > the new rewrite for inclusion in django core is moving to a way of describing > schema changes in a declarative way that can be introspected (so current > state is calculated from all previous migrations instead of some frozen state) > > this also allows large chunks of historic migrations to be squashed into new > "shortcut" migrations which sounds nice > > i'm not familiar with alembic (nor south) internals, but this sounds like an > interesting idea. > > is it something you have considered? OK the three systems I can see are 1. database introspection 2. "freezing" the last known state of the database schema as described in the application and 3. constructing the current state of the database based on the migrations present. #1 is what we do now, it has the issue that there are some mismatches between what the database can tell us about the schema versus how the application describes the schema; information is invariably lost. #2 is what I've planned for, in some way. The purpose of storing the previous value of the metadata is so that we can answer the question, "what changes were made to this MetaData structure". I guess what's "messy" is that we have to store this new thing, the previous state of MetaData, but its a thing that is designed to store exactly the state we need to know about. #3, I don't see how that could work without the requirement that the database was 100% built from scratch from migration directives, all those migration directives remain present, and they all correspond perfectly to the schema as described in the application. A large number of apps including my own were not built from scratch from migrations. Corresponding migration directives to a schema seems really complicated and would have lots of cases that don't work - literal SQL directives, custom directives, directives that were hand-edited by the user to suit various cases, directives that are in migration scripts but are not represented in the fixed metadata. That is, unless the system is, that you store the previous and new state of the fixed metadata in terms of "diff" directives that actually faithfully represent exactly changes in the metadata, and are not generally edited or mutated. So instead of storing just the "previous" version of the metadata, you actually store the observed diffs each time along with the version id. Which might be a nice idea because then you are storing a record of the whole thing, and also this is data that we already know how to get since it's essentially what autogenerate works with internally anyway. I'm not sure what actual advantages it has, I guess you could use it to produce the state of your MetaData structure for any version, if I could think of a reason why that's useful. I'll think about if there are some other wins from that approach, but it still means storing a new set of data that's independent from the user-edited migration scripts. Maybe South's approach is "messy" just because they implemented it messily? I'm not rushing into doing this feature because when I do it, it's going to be *perfect*. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
