On Wed, Jan 22, 2014 at 12:26 PM, Andrew Godwin <[email protected]> wrote:
> On Wed, Jan 22, 2014 at 5:15 PM, Michael Manfre <[email protected]> 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. > The only backends that can ever claim "fully-supported" are those included in Django. All other backends rely upon Django internals that can, and do change in backwards incompatible ways. There is a difference between the framework providing a feature and a feature being useful/required for a project/environment. E.g. GIS, template engine, or if we want to stick to just the ORM features, select related, distinct on, etc. The follow up question is, if a backend doesn't support schema alterations, should Django stop it from working? This would go against the common mantra of "we won't include it in Django, but we'll make it possible." 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. > I prefer having an explicit DatabaseFeature to disable alterations. With that feature, the base SchemaEditor could check that feature to either noop or raise NotImplementedError for the alterations. Requiring a backend to both set the feature and then noop/raise all of the methods controlled by the feature seems redundant. 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 [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/CAGdCwBvT6rK_ZMz5fFh2d261X%2BsSB5KA4_XpBYwt7dW%3DdSh6dg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
