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
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.
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.
