On 21/03/12 13:27, Kushagra Sinha wrote:
One more thing:
The current creation API in django has methods like "sql_create_model"
which basically return sql and it is the caller's responsibility to
either call cursor.execute on it (syncdb) or output the sql itself (sql).
South's (and xtrqt's) design is to have functions like "create_table"
which execute the sql themselves. Makes little difference to commands
like syncdb when they will be rewritten but commands like sql will have
to so something like start_transaction, get_sql, rollback_transaction
which is kinda hackish according to me.
What should be the design of the new migrations api?
Choosing one of these options and justifying it is a decent part of the
application :)
I'd suggest not having multiple functions to do the same thing, but
rather a modification of the South API to allow it to output SQL
(probably replacing the dry-run mode). It won't be possible for all the
South functions, but crucially it will be possible for the functions in
.creation you'd be replacing.
Of course, this method carries with it a high testing cost as you'll
have to essentially remove .creation, migrate all the core code over to
the new stuff, and add a new shim back into .creation for the bits you
replaced. You'll also have to consider what happens to apps like
GeoDjango throughout all this.
You may want to opt for the simpler method and just get .alteration
working for now and mirror some of the methods. Just make sure that
whatever you choose, it fits into the schedule, and you can justify it.
Andrew
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
