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".... ???)
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?
derek
Russell Keith-Magee wrote:
> On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> Russell Keith-Magee wrote:
>>> I'm not sure where you got the idea that automatic introspection is
>>> the issue - the proposal I put forward included automatic
>>> introspection. The issue has always been the aka syntax, and the
>>> consequences of that syntax on the overall design.
>> because several of the complaints you've and others have listed would
>> apply to any automatic introspection implementation. (most memorably
>> the 'round-trip-change' data issue) but if i'm mistaken i apologize.
>
> My objection was to the equivalence between A->B->C and A->C under
> your proposal. This is mostly a consequence of the limitations of the
> aka-syntax as applied to introspection. I have no problem with the
> concept of introspection itself, and the proposal I floated
> specifically mentions introspection as a tactic that can be used, both
> for validation and for identifying required migrations.
>
>> btw, i must have missed your proposal. (unless you're referring to your
>> 8/4/2007 email?) link?
>
> http://groups.google.com/group/django-developers/browse_thread/thread/da7831d08081d7b7/49347e67d22fa3cc?rnum=1#49347e67d22fa3cc
>
>>> Derek - on a housekeeping issue - are you happy for us to write-lock
>>> the schema-evolution branches and close the outstanding tickets in
>>> Django's ticket database relating to that branch?
>> if you don't mind, i'd prefer you keep them open, lest as you suggest we
>> get sudden fame and fortune and merging re-enters the realm of distant
>> feasibility. :) (maintaining should be pretty easy anyway, once the
>> majority of it is separated. i'll make that call once we release, i'm
>> just not ready to commit to it yet)
>
> No problems.
>
> 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
-~----------~----~----~----~------~----~------~--~---
