On Wed, Jan 22, 2014 at 5:15 PM, Michael Manfre <mman...@gmail.com> wrote:
> > 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. > I would say "yes", if something wants to claim to be a fully-supported Django backend. In this day and age being able to alter the schema is something that a framework/ORM should be providing, IMO. > 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. > I'm not sure if sniffing is the correct way, but I agree we should have either that or a direct attribute on Features that can say if a backend supports certain operations (we already have this to some extent with parts of SchemaEditor, with things like supports_foreign_keys), and then we can skip tests based on those. > 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. > I wouldn't mind keeping actual database creation separate - it doesn't really belong in SchemaEditor and is mostly used for SQLite and testing anyway - but the bits of DatabaseCreation that make tables have to go. > 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. > It's just time constraints. While that API is technically private, some things use it and I've done a lot of deep changes as it is without diving in there and possibly introducing backwards-incompatible code (we'd lose the syntax highlighted SQL too for command line output but that's not a massive loss, and should be done by e.g. pygments anyway). There's several bits in there and introspection that are only around because removing them was too much of an ask to do in the same release we add all the new stuff. I do need to stick a PendingDeprecationWarning on it though. > 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. > When you say "provided", what do you mean? The current base SchemaEditor provides a lot and once we've fixed up some of the issues you raised with the MSSQL patch it should be a lot better, certainly within reason to inherit it and just set the alteration stuff to NotImplementedError. Andrew -- 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/CAFwN1uq79C9Nqybfkp%2By9QDj4XvOnAXTE1ipUmWMBF_9ZT6wEw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
