Paul Davis wrote:
>
> As near as I can tell these are the main issues that don't seem to be
> resolved:
>
> 1. Balancing ease of use with power of use (Ie, Alice vs. Carol)
> 2. Level of versioning: Model vs. Application vs. Entire database
> 3. Application of versions: v1 -> v2 -> v3 =? v1 -> v3
> 4. How do we represent a migration from state 1 to state 2
> #1 is a nobrainer. We want both. And we won't settle for less.
agreed. this is why fingerprinting, versioning and controlled
deployment scripts are all optional in my implementation. (as i feel
they must be to support alice)
> #2 There is a lot of talking around this issue but I haven't seen
> anyone take it full on.
> We have to version the entire schema as a single object. Anyone in
> doubt, I refer to SVN's repository wide versioning vs CVS's file
> specific versioning.
i agree that at _least_ applications need to be versioned together. i
lean towards agreeing that we should version entire schemas, but w/
django not having any existing inter-app dependency mechanism (other
than they just won't work), i was reluctant to mandate it. mostly
agree, but i think the ramifications need to be better thought out
before we push it on anyone.
> #3 There are those that think v1->v2->v3 == v1->v3. I am not one of
> those people.
> A database is defined (in my mind) by its schema and the data it
> contains.
i think it depends on who you are. for alice at least, can you agree it
will be true? for the majority of apps/developers too, i'd argue. but
for disburse deployments, i've conceded before that support needs to be
there for v1->v2->v3. (and it is supported via my controlled deployment
scripts)
> Migrations are non-linear.
thank $DEITY someone else said this. :) imho any controlled deployment
system that _only_ supports lists of sequential versions is DOA.
> #4 This is minor, but I felt it necessary to say that we're obviously
> going to need python scripts to go from state to state. And custom sql
> would be easy to integrate.
agreed.
> So those are the main points near as I can tell. Now I'll go over some
> of the popular topics I saw:
>
> 1. The use of introspection:
> Will introspection be used? Of course. Will it be *all* thats used? Of
> course not.
agreed, but i think the controversy is over using introspection to
_generate_ our guesses. (heck even syncdb uses introspection - noone's
arguing we shouldn't use any)
> 2. The famous 'aka' syntax. For those of you out there saying that
> this is absurd and doesn't provide any information, I'm thankful. The
> syntax is horrible. Remember my quip about SVN vs. CVS versioning?
> This is like some ultra brain dead system that trys to version
> individual lines in a file. I mean, not even CVS is that bad.
you're confused as to it's purpose. it is certainly *not* an attempt to
version anything. it's there as a necessary hint to the guess_generation
routine. i think everyone acknowledges we need some sore of a hinting
syntax on top of the version tracking if we want to do any generation of
change scripts... the question is where?
the reasons i put it where i did are as follows:
1) easy to use / grok for everyone, even for alice.
2) all field referencing has some ambiguity, if you want to
support fields that no longer exist.. best to have only
one side ambiguous by attaching it directly to the other.
i agree it would be a brain-dead VCS implementation, but it's not. so
that being understood, is it more palatable now?
derek
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
