On Wed, Jan 22, 2014 at 6:40 AM, Andrew Godwin <and...@aeracode.org> wrote:
> My thoughts in brief on this: > > - Database backends don't support migrations - they support schema > alteration via SchemaEditor. This could be used separately from migrations > if something wants it, and is meant to be an API on its own, so the backend > is not the place to say if you want migrations or not. > I've been using migrations to refer to migrations and the the schema alterations done by SchemaEditor since migrations depend on SchemaEditor being able to do the alterations it wants. I'll try to respect the distinction going forward to avoid confusion. My request would probably be better read as "Must a database backend support schema alterations?", which also implies its ability to do a migration that alters the schema. Data only migrations would still technically be possible without the ability to alter the schema, but I'm not sure if that functionality would be as useful by itself. - There is some merit to the ability to turn off migrations on a > per-backend basis, via a DATABASES setting, but bear in mind that routers > already let you do this (with the allow_migrate method). The only extra > thing it would achieve is not having Django record migrations in the > django_migrations table, but it also looks like it would be useful for > tests if you hadn't written that part yet. > > - I feel like a DB backend should at least implement SchemaEditor even if > it returns NotImplementedError for most of the endpoints; even in the > weirdest relational system, you can still manage create/delete model > without too much difficulty. > I think we all agree that any database backend must continue to be able to create or delete schema objects, or provide something like Oracle's TEST_CREATE setting to allow that to be done as a non-Django step. I think it is reasonable to require any backend to support that portion of SchemaEditor. I think we should have a property on DatabaseFeature that sniffs SchemaEditor to figure out whether it supports alterations. That would let us use the existing database feature decorators to skip tests. - Bear in mind that the plan is to remove DatabaseCreation entirely in > favour of SchemaEditor in a few releases' time (and backends are more than > welcome to make DatabaseCreation use SchemaEditor behind the scenes if they > want), so at that point if you don't implement it the backend is only ever > good for querying, which to me feels like an incomplete backend. > I'm not sure I like this generic plan, but I don't have all of the details and the discussion can be deferred until a later date. There is some value in having a distinction between something that creates just the databases (or files) and something that creates the schema inside of the databases. Other than time constraints, is there a reason not to update DatabaseCreation in Django 1.7 so that is little more than a proxy to SchemaEditor for the create/delete sql? I think we all agree that any database backend must be able to create/delete the schema, so I don't think it makes much of a difference whether that happens in DatabaseCreation or SchemaEditor. All of the database backend API has been deemed internal API on several occasions, so it should be safe to make this sort of change and also not necessarily be subject to the alpha feature freeze. I'd be happy to work on this. > - I'm not sure what the future of ./manage.py sqlall is, but it's going > to have to be ported to SchemaEditor in future anyway, so it's only useful > in the transition. > > Looking at the discussion, I think the best thing to do is: > > - Make the schema and migrations test skip if connection.schema_editor() > raises a NotImplementedError (not too hard, we can implement > connection.has_schema_editor as a boolean to switch on) > - Provide some way to skip the "creating models" part of test setup, so > SchemaEditor is never needed during it > I think it's okay to require SchemaEditor to exist with minimal functionality. It would be ideal if this minimal SchemaEditor was provided. Disabling the alterations with a DatabaseFeature would make the existing BaseDatabaseSchemaEditor on par with BaseDatabaseCreation's ability to create/delete schema objects. > I still think all the current third-party backends should be able to > provide a partial SchemaEditor implementation though, as at minimum they > all have the DatabaseCreation code in place to make new models. Bear in > mind that the ./manage.py sqlmigrate command lets you turn migrations into > SQL scripts to send to your DBA (and many DBAs appreciate having some SQL > they can work from - I know ours do), so having the ability to make that > SQL is useful even if Django never runs it. > Agreed. DBAs are happier to have a non-blank starting point. Regards, Michael Manfre -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBsqneiXN7aP%2BVR_6WLeDYX-cMJ0zcpK5rCpOYQsRJOsRg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
