On Wed, Jan 22, 2014 at 12:26 PM, Andrew Godwin <and...@aeracode.org> wrote:
> 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. > 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 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/CAGdCwBvT6rK_ZMz5fFh2d261X%2BsSB5KA4_XpBYwt7dW%3DdSh6dg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
