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? Any thoughts on this? On Tue, Mar 20, 2012 at 3:47 AM, Andrew Godwin <and...@aeracode.org> wrote: > On 19/03/12 20:33, Kushagra Sinha wrote: > >> Andrew's thread[1] also mentions - "backends will always be able to >> generate SQL for operations, but it won't necessarily be runnable >> (things like index names can only be resolved at runtime, so you'd get >> code like "DROP INDEX <<User.username-index>> ON users;"." >> >> [1] >> https://groups.google.com/**forum/?fromgroups#!topic/** >> django-developers/usFXJvpelmI<https://groups.google.com/forum/?fromgroups#!topic/django-developers/usFXJvpelmI> >> >> Am I correct to assume that the plan is to allow migration files in >> python as well as pseudo-SQL like above? >> In that case, I think will concentrate on just the core part of >> migrations API and nothing else as far as GSoC is concerned. >> > > The actual migration file loading/running system was never intended to be > part of the GSOC (nor my port when I was planning it) - the idea was to get > just the database API in for a release, allowing South to lose all that > code, then work on a migration file/running/dependency API for the next one. > > There's a lot more potential bikeshedding and design issues with writing a > migration-running API, so that's one of the reasons it's separated out. I'd > highly recommend focusing just on the database API - what's in South > currently can't be ported straight across, and it needs quite a bit of > cleanup (especially in the SQLite code), so it's still a decent amount of > work. > > > > Another query: >> Andrew's thread above also mentioned: >> Some of these operations are already mostly implemented (add_table, >> add_index, etc.) in backends' creation modules, but they'll need a bit >> of rearranging and separating into a full public API. I also plan to >> modify them to take model names and field names, instead of table names >> and column names, so the API is exclusively using the Django model layer >> to represent changes (there's a possibility that some changes make sense >> for schemaless databases as well, specifically renames, so it's best not >> to tie it directly to relational databases). >> >> As it happens xtrqt last year had implemented, documented and tested the >> migrations API for at least SQLite[2]. However he used explicit table >> and column names in his API methods. Obviously he put the task of table >> name translation on the API caller. Is there any consensus on the API >> design regarding this point? >> > > I feel that table names should definitely be explicit, as models expose > their expected name. Column names are harder if you accept Django fields as > valid inputs for the type - South currently uses implicit column names in > add_table (i.e. _id gets auto-added) and explicit elsewhere. I'd rather it > was explicit everywhere, and the field's column information was ignored in > the schema alteration API (it's the migration runner's job to feed it the > right stuff, I'd say). > > Don't rely too heavily on xtrqt's work from last year - the work that was > done was basically a copy of South's code into a new module with a few > minor changes. We're looking for a more extensive, clean move, with some > partial rewriting - in particular, I'd like to make the dry_run system more > sensible (or possibly drop it in favour of having a SQL generation mode > that would serve a similar purpose). > > SQL generation itself would be a nice feature - it's not always possible > (delete_index, delete_unique), but something that tries where it can, and > puts comments/invalid SQL where it can't, would be nice. > > 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<django-developers@googlegroups.com> > . > To unsubscribe from this group, send email to > django-developers+unsubscribe@**googlegroups.com<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at http://groups.google.com/** > group/django-developers?hl=en<http://groups.google.com/group/django-developers?hl=en> > . > > -- 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.
