Hi Marcin, I don't believe it's some sort of ethos that got Andrew to collaborate with Django and create the current migration framework: It's the fact that pretty much everyone who used Django also used South that convinced Andrew to recreate its behaviour as a core Django app.
I'm not saying that Liquibase isn't useful -- I haven't really investigated the project you're pitching. I'm simply saying that migrations are considered a necessary feature for any decently-sized project, and currently Django's way of supplying this is its core migration framework. If you are able to patch Django's behaviour to not depend on its core migration framework, but to depend on a pluggable migration backend, I'm sure everyone will be very happy to see that as a Django core feature. But as is currently stand, it's a lot of work to recreate the Django migration framework as a pluggable backend, and it's not worth it if there isn't a tightly integrated migration framework that picks up the changes to Django models. It should still be quite easy to use Liquibase for your database management: simply set your models as `managed=False`, and you'll have full control over your database. You'll simply have to keep your Django models up-to-date to use them. With king regards, Marten Op maandag 27 april 2015 02:33:44 UTC+2 schreef Marcin Nowak: > > Hi. > > Before v1.7 there were no migrations and Django was quite useful (for > example with South as an 3rd party app). What happened then? > > I think that migrations can be decoupled from core and you just don't want > to do this for some unknown reason. > I'll prepare a pull request if it will not be dropped because of some kind > of ethos. > > BR > Marcin > > On Saturday, April 18, 2015 at 5:03:39 AM UTC+2, Markus Holtermann wrote: >> >> Hey Marvin, >> >> Unfortunately this won't work as a few migration components are tightly >> integrated into remaining parts of Django, e.g. the field deconstruction. >> >> /Markus >> >> On April 18, 2015 3:35:09 AM GMT+02:00, Marcin Nowak < >> [email protected]> wrote: >> >Hi. >> >Just give people possibility to disable migrations functionality >> >(remove it >> >from core and put as a contrib app, if needed). >> > >> >/BR >> >Marcin >> > >> > >> >On Thursday, January 22, 2015 at 8:09:01 PM UTC+1, Andrew Godwin wrote: >> >> >> >> Aha! Then, I would suggest redesigning MigrationRecorder to only make >> >the >> >> table when an actual recording operation is done, and have it swallow >> >the >> >> table not existing as "no migrations applied" the rest of the time, >> >if >> >> people think that seems sensible. >> >> >> >> Andrew >> >> >> >> On Thu, Jan 22, 2015 at 10:44 AM, Markus Holtermann < >> >> [email protected] <javascript:>> wrote: >> >> >> >>> Hey, >> >>> >> >>> as soon as the MigrationRecorder is used there is a call to >> >>> "ensure_schema" that forces the creation of the migration table. The >> > >> >>> runserver command (among others?) checks for unapplied migrations >> >and thus >> >>> creates the migration table. >> >>> >> >>> /Markus >> >>> >> >>> On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin >> >wrote: >> >>>> >> >>>> Hi Ivan, >> >>>> >> >>>> I'm not sure what you're asking here - are you asking to have a way >> >to >> >>>> not have Django create the migrations recording table? I was under >> >the >> >>>> impression that it was only created when migrate was run (at least, >> >that >> >>>> was my original intention) so if you're managing your own schema >> >just don't >> >>>> run migrate. Is there something else that's not working right, or >> >is that >> >>>> being made too optimistically? >> >>>> >> >>>> Andrew >> >>>> >> >>>> On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel <[email protected]> >> >wrote: >> >>>> >> >>>>> From Andrew: "The only extra thing it would achieve is not having >> >>>>> Django record migrations in the django_migrations table" >> >>>>> >> >>>>> The Django Users thread on how to keep this table from being >> >created >> >>>>> seemed to result in the 'solution' being either to stay with 1.6 >> >or comment >> >>>>> the relevant lines in the Django code base. Is there really no >> >other way? >> >>>>> >> >>>>> I love the new migrations facilities in Django 1.7 and was a >> >>>>> contributor to the kickstarter but please keep in mind that many >> >legacy DB >> >>>>> projects are not avoiding migrations because they want to. IMO >> >it's usually >> >>>>> because they are forced to for some (usually political) reason >> >where they >> >>>>> don't have control over the schema. Forcing a perpetually empty >> >>>>> django_migrations table pretty much locks out those users. >> >>>>> >> >>>>> I see that people are worried about encouraging the non-use of >> >>>>> migrations but might I suggest following the Zen of Python and >> >making >> >>>>> migrations the "one obvious way to do it" and turning them off the >> >not >> >>>>> obvious way. >> >>>>> >> >>>>> Ivan >> >>>>> >> >>>>> On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin >> >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. >> >>>>>> >> >>>>>> - 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 (Contributions to Django itself)" 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/e3bd21ad-6aec-4686-a037- >> >>>>> 69d486f969a9%40googlegroups.com >> >>>>> >> >< >> https://groups.google.com/d/msgid/django-developers/e3bd21ad-6aec-4686-a037-69d486f969a9%40googlegroups.com?utm_medium=email&utm_source=footer> >> >> >> >>>>> . >> >>>>> For more options, visit https://groups.google.com/d/optout. >> >>>>> >> >>>> >> >>>> -- >> >>> You received this message because you are subscribed to the Google >> >Groups >> >>> "Django developers (Contributions to Django itself)" group. >> >>> To unsubscribe from this group and stop receiving emails from it, >> >send an >> >>> email to [email protected] <javascript:>. >> >>> To post to this group, send email to [email protected] >> >>> <javascript:>. >> >>> 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/81dcde2e-babb-4714-829e-b9308f3672cd%40googlegroups.com >> >> > >> >>> >> >< >> https://groups.google.com/d/msgid/django-developers/81dcde2e-babb-4714-829e-b9308f3672cd%40googlegroups.com?utm_medium=email&utm_source=footer> >> >> >> >>> . >> >>> >> >>> For more options, visit https://groups.google.com/d/optout. >> >>> >> >> >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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/8eb0f963-1cb1-4115-bb1d-09f0574c21f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
