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.
- 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. - 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 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 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. Andrew On Wed, Jan 22, 2014 at 10:10 AM, Shai Berger <[email protected]> wrote: > On Wednesday 22 January 2014 16:26:50 Russell Keith-Magee wrote: > > On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger <[email protected]> wrote: > > > > > > B) Allow the test suite to run on an existing schema. The Oracle > backend > > > already does this (badly) -- its six specific TEST_* parameters are > > > awkwardly named, but allow you to say exactly which schema to use for > > > testing, and whether or not you want it created. If this is made more > > > general, then testing can be made to not depend on migrations; with no > > > migrations, you will need to take care of the test database yourself -- > > > just like you take care of the production database. > > > > > > For Django's own test-suite, tests which need migrations can even be > > > automatically skipped if getting a schema_editor raises a > > > NotImplementedError; allowing a backend to easily (well, relatively > > > easily) pass the suite without implementing migrations. > > > > This last bit is the critical part. At present, we don't have any > > infrastructure to allow tests to be skipped because of a lack of > migration > > support. All Django's officially supported backends support migrations, > so > > there hasn't been any need to skip any tests. > > > > The question is whether we should allow for this for third party > backends. > > > > Historically, the test for a "Django 1.X supported backend" has been > > "Passes the Django 1.X test suite without errors."; database features > have > > been added to allow checking for specific known problems on specific > > backends (vendor-specific index name size limits, for example), but not > for > > entire features. The proposal here is to provide a similar flag for > > migrations, enabled for all the builtin backends, so that you could have > a > > "compliant" 1.7 database backend without supporting migrations. I'd argue > > this isn't something we want to encourage. > > > I agree -- it wasn't my intention to mark such backends as fully supported, > but as "supported with a caveat". > > However, I do think the ability to say "I've got this half of the > functionality covered" is important. Further, since the DML part of SQL is > much more consistently implemented than the DDL part, the part without > migrations is a lot easier to implement than the migrations; the validation > should be pretty encouraging for 3rd-party backends. > > So, I rephrase my suggestion for the Django tests: > > For Django's own test-suite, tests which need migrations can be > automatically skipped if Russell's suggested "no migrations" DATABASES > setting is set; allowing a backend to easily validate its migration-less > part. > > Shai. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/33933764.nuWK3GA93E%40deblack > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAFwN1uozi88S-Z8GeOmfD14VkU5%2BUXdnNBFG6cm9DvBv2XBV-w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
