Turn off migrations completely in Django 1.7

[Anthony Tuininga]

Hi,

I just upgraded my test environment to Django 1.7 and immediately noticed that mgirations appear to be a requirement. Searching the documentation and the code itself seems to indicate that there is no way to disable it, either. Did I miss something? I don't need or want Django to create or alter any database objects and up to Django 1.6 I could quite happily ignore syncdb but it seems I can't ignore migrations. Please advise! Thanks.

Anthony

[m1chael]

Hi,

I feel your pain, but I think you can utilize something with --fake

I have been using databases for many, many years, and honestly-
migrations definitely make sense. I am able to add new fields within a
few seconds without having to do any extra work. It takes 2 minutes to
learn how to use migrations, and I will personally never look back.

Mike

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/9bdd258f-a21b-48a0-ab1b-b3a4123b40c1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nikolas Stevenson-Molnar]

You could always set your models to managed=False https://docs.djangoproject.com/en/dev/ref/models/options/#managed

_Nik

[Anthony Tuininga]

Hmm, the problem is that there doesn't appear to be any way to turn off the creation of the migrations table itself, even if all of the other models are set to managed=False as suggested by Nikolas. I've commented it out for now but it would be ideal to have some way of turning it off completely -- or simply doing nothing if there are no managed models.

[marcin....@gmail.com]

So what about that? I'm also interested in disabling migrations. 

I need to upgrade Django in big project (from 1.4 to newer version) because of lack of support for 1.4, but migrations included in v1.7 will complicate this process. 

I want to disable everything related to migrations. We're using better migration solution, which is project-wide and related only to databases. 

Django is a only small part of the project and it should not modify any table and any record outside our migrations system.

/BR

Marcin

[Mike Dewhirst]

On 27/04/2015 9:54 AM, marcin....@gmail.com wrote:
> So what about that? I'm also interested in disabling migrations.
> I need to upgrade Django in big project (from 1.4 to newer version)
> because of lack of support for 1.4, but migrations included in v1.7 will
> complicate this process.

Would it suffice to have all your models specify "managed = False" in
the Meta class?

https://docs.djangoproject.com/en/1.7/ref/models/options/#managed

Mike

> <http://groups.google.com/group/django-users>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/django-users/9bdd258f-a21b-48a0-ab1b-b3a4123b40c1%40googlegroups.com

> <https://groups.google.com/d/msgid/django-users/9bdd258f-a21b-48a0-ab1b-b3a4123b40c1%40googlegroups.com>.

>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto:django...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-users/1f03aaad-1beb-4b84-9ca3-c1ce097ad0ca%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/1f03aaad-1beb-4b84-9ca3-c1ce097ad0ca%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jamie Lawrence]

On Apr 27, 2015, at 7:01 PM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
>
>> On 27/04/2015 9:54 AM, marcin....@gmail.com wrote:
>> So what about that? I'm also interested in disabling migrations.
>

> Would it suffice to have all your models specify "managed = False" in the Meta class?
>
> https://docs.djangoproject.com/en/1.7/ref/models/options/#managed

This is why top posting or at least failing to trim is bad for (at least) technical mailing lists. Threads end up looping.

From the very email quoted:

[Mike Dewhirst]

Jamie

Well I agree top-posting is usually a problem - especially for those who
hate it. But in this case the top-poster was semi-hijacking the thread
and in doing so felt the need to top post to differentiate the subject
matter. That difference was in "disabling migrations" versus turning off
migrations completely and preventing the creation of the migrations
table - the latter not something the top poster seemed to worry about.
Also, there is the line "even if all of the other models are set to
managed=False" which implies another difference possibly justifying a
thread semi-hijack. Anyway, I suspect disabling migration - even if a
"master-switch" could be built - is undesirable if one is using any of
the django tables.

Please forgive me for hijacking this thread to discuss top-posting.

Mike

[marcin....@gmail.com]

On Tuesday, April 28, 2015 at 7:20:17 AM UTC+2, Mike Dewhirst wrote:

Anyway, I suspect disabling migration - even if a
"master-switch" could be built - is undesirable if one is using any of
the django tables.

I'm not sure we're talking about the same.

Some of us don't need builtin migration system. It is badly designed, same as South was.

I know that we can make simple migrations in seconds, but we're wasting hours elsewhere.

Database migrations should be managed by database tool. 

"Model migrations" are fiction... this is a conceptual mistake. There are no models mapped to db tables - there are tables mapped to models.

We're working with databases and their representations in application layer, and not vice versa.

 

Thanks,

Marcin

[Avraham Serour]

> We're working with databases and their representations in application layer, and not vice versa.

Speak for yourself, I'm working with the models, saving them in the database is just an implementation detail

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.

Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/de18bd57-ad18-4464-8783-009e26abced2%40googlegroups.com.

[Marcin Nowak]

On 25 August 2015 at 14:32, Avraham Serour <tov...@gmail.com> wrote:

> We're working with databases and their representations in application layer, and not vice versa.

Speak for yourself, I'm working with the models, saving them in the database is just an implementation detail

I'm speaking on behalf of a one of experienced developers, who knows that data is most important thing in IT.

And this is not an implementation detail, because the bulit-in tool is forcing us to do things in the your way/workflow, and sometimes blocks us. Let the user decide which tool is better for his job.  

Marcin

[bobhaugen]

I agree that migrations should be optional, for all the reasons listed in this thread, but hope it doesn't now turn into a religious war between models-first and database-first. Not relevant to the issue.

[Tim Graham]

What does "turning off migrations" mean in practice? Is it not enough to avoid the makemigrations and migrate management commands?

[Marcin Nowak]

On 25 August 2015 at 16:21, Tim Graham <timog...@gmail.com> wrote:

What does "turning off migrations" mean in practice? Is it not enough to avoid the makemigrations and migrate management commands?

Currently I'm replacing mgmt commands to avoid accidential calls, and also replacing test runner.  But, for example, `runserver` complains about unapplied migrations (which is not true), and I don't know what else and when other db alterations can be executed. 

"Global turn off" should give us assurance that nothing would be changed in db automatically.  

BR,

Marcin

[Carl Meyer]

On 08/25/2015 08:42 AM, Marcin Nowak wrote:
>
> On 25 August 2015 at 16:21, Tim Graham <timog...@gmail.com

I thought we already covered this topic, and `managed=False` should work
for your use case. That's the exact meaning of this flag: "I don't want
Django to manage my database, please never touch it." Have you tried
adding that flag to your models? Does something about that not work for you?

Carl

[Marcin Nowak]

On 25 August 2015 at 16:53, Carl Meyer <ca...@oddbird.net> wrote:

I thought we already covered this topic, and `managed=False` should work
for your use case. That's the exact meaning of this flag: "I don't want
Django to manage my database, please never touch it." Have you tried
adding that flag to your models? Does something about that not work for you?

Managed=False is not same. I.e. I can't set managed=False for 3rd party apps (including `django.contrib`)

But to be honest I didn't tried iterate over all INSTALLED_APPS to patch meta options...

BR,

Marcin

[Carl Meyer]

On 08/25/2015 09:02 AM, Marcin Nowak wrote:
>
> On 25 August 2015 at 16:53, Carl Meyer <ca...@oddbird.net

Hmm, yes, third-party apps are an issue.

My recollection from the last time you brought this up is that we
decided an AppConfig-level setting to do the equivalent of managed=False
for an entire app would be a reasonable feature request. Since you can
provide your own AppConfig for third-party apps, this would cover that
use case, too.

Carl

[Marcin Nowak]

On 25 August 2015 at 17:04, Carl Meyer <ca...@oddbird.net> wrote:

Hmm, yes, third-party apps are an issue.

My recollection from the last time you brought this up is that we
decided an AppConfig-level setting to do the equivalent of managed=False
for an entire app would be a reasonable feature request. Since you can
provide your own AppConfig for third-party apps, this would cover that
use case, too.

That would be a better than nothing and it's flexible.

But in the most of my cases I will need to provide app configs for all apps. This can mean a lot of unnecessary work.

Something like 'disable all' is simplest solution, but naturally limited.

Maybe there is a solution for both?

BR,

Marcin

[Carl Meyer]

On 08/25/2015 09:23 AM, Marcin Nowak wrote:

> On 25 August 2015 at 17:04, Carl Meyer <ca...@oddbird.net

Sometimes when you have unusual requirements you have to do a little
more work to meet them. To my knowledge, out of the many hundreds of
thousands of Django users, you are the first and only one to request a
way to turn off migrations entirely. So I don't think there is a very
strong need to make that easy, when we can add a more flexible feature
that makes it possible.

It is not possible to build a framework where _everything_ is easy. We
aim for "Simple things should be easy, advanced things should be possible."

Carl

[Marcin Nowak]

> Maybe there is a solution for both?

Sometimes when you have unusual requirements you have to do a little
more work to meet them. To my knowledge, out of the many hundreds of
thousands of Django users, you are the first and only one to request a
way to turn off migrations entirely.

Maybe no one else talks about it. I don't believe that there are no other database-centric projects, where Django is used to map (external) database tables to objects and generate some HTML or RESTful output.

 

It is not possible to build a framework where _everything_ is easy. We
aim for "Simple things should be easy, advanced things should be possible."

Well.. I would like to do something as hard as usual, but turn off some unnecessary stuff. Same as not including "django.contrib.admin" in INSTALLED_APPS, same as switching template engine to Jinja2, or same as removing unnecessary middleware. 

I just thought that skipping some function calls is simplest than creating new feature for building workarounds, and even will be shorter than time for talking about it. But I was wrong. 

BR,

Marcin

[Marcos Eliziario]

Changing the database accidentally can be avoided simply by adjusting the privileges of the database user django uses.

Flexibility in a software project always come out at the expense of simplicity. So, generally, django developers are right to avoid rarely need features in exchange for a simple, more testable code base.

It may look simple, but in the end it is not. Think about all the tests that presume you have migrations enabled, your simple change would require new tests to try to ensure it doesn't break anything and at least a thorough check.

The thing is, nobody ever requested that, it is not a popular feature request, so, it is not there and won't be there unless someone contributes with a solid patch and a solid case for this added complexity

[Marcin Nowak]

On 25 August 2015 at 18:44, Marcos Eliziario <marcos.e...@gmail.com> wrote:

Changing the database accidentally can be avoided simply by adjusting the privileges of the database user django uses. 

It's not perfect. The connection requires write access and Django inserts some data automatically. 

But table-level grants can be a paritial solution. 

   

And still Django complains about unapplied migrations...

The thing is, nobody ever requested that, it is not a popular feature request, so, it is not there and won't be there unless someone contributes with a solid patch and a solid case for this added complexity

I would like to provide solid patch as a pull request, but I'm afraid that it will be rejected due to some kind of spirit, politics or something else. 

BR,

Marcin

[Remco Gerlich]

On Tue, Aug 25, 2015 at 5:27 PM, Carl Meyer <ca...@oddbird.net> wrote:

To my knowledge, out of the many hundreds of
thousands of Django users, you are the first and only one to request a
way to turn off migrations entirely.

I think that's a little unfair, given that migrations are only in Django since 1.7, which isn't even a year old yet. On older versions it was just a matter of not using South. I think there are quite a lot of < 1.7 projects that don't use South.

That said, another way not mentioned yet: database routers have an allow_migrate method. Maybe use a two-database solution with a router, one database for the Django-internal tables that want to be able to migrate, and one for your company's data that always returns allow_migrate False?

Greetings,

Remco Gerlich

[Grzegorz Stalmierski]

W dniu 25.08.2015 o 19:04, Marcin Nowak pisze:

I would like to provide solid patch as a pull request, but I'm afraid that it will be rejected due to some kind of spirit, politics or something else. 

BR,

Marcin

Marcin, please - consider sharing your patch on GitHub (or similar)
with a documentation, because:

It is not possible to build a framework where _everything_

 is easy. We
aim for "Simple things should be easy, advanced things should be possible."

Carl

this is not so advanced thing, and it looks almost
impossible to solve in Django.
With current architecture around migrations Django
is database owner, not one of the database services.

I'm almost certain this patch will gather new contributors.

--
Regards,
Greg

[Carl Meyer]

Hi Grzegorz,

On Aug 26, 2015, at 2:25 AM, Grzegorz Stalmierski <grzegorz.s...@gmail.com> wrote:

W dniu 25.08.2015 o 19:04, Marcin Nowak pisze:

I would like to provide solid patch as a pull request, but I'm afraid that it will be rejected due to some kind of spirit, politics or something else. 

BR,

Marcin

Marcin, please - consider sharing your patch on GitHub (or similar)
with a documentation, because:

It is not possible to build a framework where _everything_ is easy. We
aim for "Simple things should be easy, advanced things should be possible."

Carl

this is not so advanced thing, and it looks almost
impossible to solve in Django.
With current architecture around migrations Django
is database owner, not one of the database services.

I agree, and I already suggested a new feature (`managed=False` at the AppConfig level) for which I think a solid patch would most likely be accepted. This new feature would be capable of handling the "don't migrate anything" case as well as the wide variety of "migrate these apps but not those" cases. 

You quoted me out of context. My quote was in reply to Marcin complaining that even _that_ feature would still be too much work to use. I wasn't claiming the status quo is sufficient for this. 

FWIW I don't think a single new setting to switch off migrations for all apps is 100% out of the question, if it turns out there are a number of people who would use it. I'd like to hear a little more specifics from such people about their use case. I don't think a global flag is as generally useful as the above feature, and it would need to come with some pretty strong warnings in the docs. For instance, Django may modify models in contrib apps and ship migrations for them in future versions, and of course third party apps will commonly do the same. So anyone using such a global flag is accepting responsibility for watching out for such schema changes themselves, or their project may break when they upgrade Django or another app. 

Carl

[Carl Meyer]

On 08/26/2015 08:15 AM, Carl Meyer wrote:
> I agree, and I already suggested a new feature (`managed=False` at the
> AppConfig level) for which I think a solid patch would most likely be
> accepted. This new feature would be capable of handling the "don't
> migrate anything" case as well as the wide variety of "migrate these
> apps but not those" cases.

Another option might be to leverage the existing `MIGRATION_MODULES`
setting, allowing a value of `None` to mean "ignore migrations for this
app, I will manage its schema myself outside of Django."

At this point the discussion belongs on the django-developers list, to
enumerate the real-world use cases and sort out the pros and cons of the
various possibilities. Getting a change into Django is rarely
impossible, but it does require committing some time and energy to
discussion and evaluation of the options.

Carl

[Grzegorz Stalmierski]

2015-08-26 16:15 GMT+02:00 Carl Meyer <ca...@oddbird.net>:

You quoted me out of context.

​I'm sorry. It was unintentional. ​

--

​Regards,

​Greg Stalmierski.​

[Marcin Nowak]

On 26 August 2015 at 16:50, Carl Meyer <ca...@oddbird.net> wrote:

At this point the discussion belongs on the django-developers list, to
enumerate the real-world use cases and sort out the pros and cons of the
various possibilities. Getting a change into Django is rarely
impossible, but it does require committing some time and energy to
discussion and evaluation of the options.

I can specifiy some use cases.

1. Using Django as a part of bigger stack, where databases are maintained by external tool and no schema nor data modifications should be applied automatically.

2. Avoiding limitations/forcings of builitin migration system and Django ORM. 

By using external database migration tool developers have flexibility and possibility to "do things right" (from db perspective).

Models are used as an read/write interface with a subset of fields. 

Anf it was working good up to 1.7, and may work good with migrations turned off. 

3. https://code.djangoproject.com/ticket/23159

Wontfix, because does not fit design concepts of migrations. Without migrations everything is OK and works as expeced. In that case migrations are not feature but a real limitation.

And last, but not real use case (just design concept): 

 

4. Improper migrations design

Django migrations are apps-related, same as South was. This is a not the best possible design.

There is, for example, possibility to generate migrations within python eggs (even in Django itself).

Migrations should be project-wide and splitted by database.

Developer should have possibility to change database schema as he need without forcing limitations of model-based migration system. 

Not every table is mapped to model.

Kind Regards,

Marcin

 

  

[Frank Malina]

RE: Carl Meyer

>> To my knowledge, out of the many hundreds of 
>> thousands of Django users, you are the first and only one to request a 
>> way to turn off migrations entirely.

No he isn't, Django migrations are ridiculous waste of time, never work and make me angry.

I work with Django from v0.96 and it never got in the way as much as it does now.

[do...@gearscape.net]

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.

> Visit this group at http://groups.google.com/group/django-users [1].

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-users/b1a2ff2b-7888-4a52-aaa8-c09a9b036838%40googlegroups.com
> [2].
> For more options, visit https://groups.google.com/d/optout [3].
>
>
> Links:
> ------
> [1] http://groups.google.com/group/django-users
> [2]
> https://groups.google.com/d/msgid/django-users/b1a2ff2b-7888-4a52-aaa8-c09a9b036838%40googlegroups.com?utm_medium=email&utm_source=footer
> [3] https://groups.google.com/d/optout

Please forgive this simple question .

How can I change the email address associated with this group ?

I want to keep getting the emails but to a different address.

Thanks

doug

[Nikolas Stevenson-Molnar]

Just unsubscribe from the list, and then subscribe again with the desired email.

Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/486d3e2e4179fbd43336f900899b7e9b%40gearscape.net.
For more options, visit https://groups.google.com/d/optout.

[john....@gmail.com]

+1 for disabling migrations completely - for several reasons.

1. Right now, I'm trying to run tests against a production database with runserver, in *read-only* mode - but it fails because it can't create the django_migrations table.  (I'm in the process of upgrading from Django 1.4 to 1.8, so the table doesn't yet exist in production.)

2. Our mysql database is 3TB, with some tables of up to 500GB - and I assume that migrating them with Django - without taking the system down for days - is not possible.  Instead, we use Percona's pt-online-schema-change, which does an excellent job of migrating big tables, whilst keeping them fully usable with no downtime.

Point 2 is covered, I think, by setting all models to unmanged, as we do - but that doesn't help me with the upgrade process in point 1 - unless I'm missing something?

(Yes, perhaps I could jump through hoops and make a second, writable database, with appropriate routers etc, to enable creation of the django_migrations table, to get past point 1 - but if django migrations are useless to us anyway... disabling migrations entirely seems far more logical.)

[marcin....@gmail.com]

On Wednesday, August 26, 2015 at 1:08:51 PM UTC+2, grzegorz.stalmierski wrote:

With current architecture around migrations Django
is database owner, not one of the database services.

Application layer is chaning over time and its lifetime is a way shorter than database and data.

Mid-level and big systems are often service oriented, where services are responsible to do things other than displaying blog page as a html.

Django should not manage their databases, or even must not. 

Django as a database owner is a nonsense in some cases.  

Don't get me wrong - builtin migrations are ok for small projects, but as a system architect I should have possibility to disable them.

When disabled, Django should not remind me about unapplied migrations and should disallow me to makemigrations or migrate db.

Also Django should dump SQL of the current models state to make diff using external tool.

That' all.

Marcin

[Matt Schinckel]

On Wednesday, December 2, 2015 at 6:31:31 PM UTC+10:30, john....@gmail.com wrote:

+1 for disabling migrations completely - for several reasons.

1. Right now, I'm trying to run tests against a production database with runserver, in *read-only* mode - but it fails because it can't create the django_migrations table.  (I'm in the process of upgrading from Django 1.4 to 1.8, so the table doesn't yet exist in production.) 

2. Our mysql database is 3TB, with some tables of up to 500GB - and I assume that migrating them with Django - without taking the system down for days - is not possible.  Instead, we use Percona's pt-online-schema-change, which does an excellent job of migrating big tables, whilst keeping them fully usable with no downtime.

When upgrading from 1.4 to 1.7+, you shouldn't be changing anything in the database. Sure, you'll want to build up the migrations, but you won't actually want to apply them, only fake them. If you are attempting to change your db structure at the same point in time as upgrading from pre-1.7 to post-1.7, you are making it much harder than it needs to be. (Yes, I'm going through the same process, with a database of similar size. Mine is postgres though).

[john....@gmail.com]

Thanks for the comment Matt.  I wasn't trying to change anything in the database, it was just that Django wanted the django_migrations table to exist, but it didn't, and the db was read-only for safety during testing.  Could well be that I wasn't using fake properly, I'm not sure, but I'd still prefer to have had the option to disable migrations entirely since in our case, they're too simplistic for migrating large tables with minimum downtime.

Either way - we recently hit another Django limitation - as best I've been able to tell, joining a table with itself seems to be very poorly supported - so we're heading towards SqlAlchemy, and probably away from Django altogether in time.

Good luck with your migration!

[Marcin Nowak]

On 21 April 2016 at 10:06, <john....@gmail.com> wrote:

Either way - we recently hit another Django limitation - as best I've been able to tell, joining a table with itself seems to be very poorly supported - so we're heading towards SqlAlchemy, and probably away from Django altogether in time.

If you're building some report-like queries, or any static queries, I would suggest to use raw sql. 

You can optionally wrap results with model instances using Model.objects.raw(). 

Previously I used SQLAlchemy together with Django, but currently I'm moving from SA to templated raw queries, because building them using any ORM is too hard to maintenance  (code is very unreadable in opposite to plain SQL). 

But embedding raw queries in Python code is generally bad, same as mixing Python together html (spaghetti code). That's why I'm working on SQL templating module based on Django` template engine. If you're interested please look at https://github.com/marcinn/django-sqltemplate/ (please note that is a alpha version, which may be unstable and API may be chaged). 

The main advantages of raw SQL are readability and no limits. Templated SQL gives you possibility to modify queries based on context variables, which is not flexible as querysets, but often good enough to do job well. But as a disadvantage you have to pay attention to SQL syntax and variables escaping.  

Kind Regards,

Marcin

[john....@gmail.com]

On Thursday, 21 April 2016 18:51:48 UTC+10, Marcin Nowak wrote:

If you're building some report-like queries, or any static queries, I would suggest to use raw sql. 

You can optionally wrap results with model instances using Model.objects.raw(). 

Thanks Marcin.  Yeah, good call perhaps.  We're certainly drawn to raw sql (which we all know fairly well) compared to learning Django's tricks for complex queries, but the originator of our project chose to write lots of unit tests using sqlite (instead of our production mysql) for speed and simplicity reasons (notwithstanding questions of incompatibility) - so an ORM offers some extra value currently due to SQL differences that can be handled automatically.  On first glance SA appears a little more like SQL than Django's query language - though I'm sure there's times when I may tear my hair out wanting raw SQL.

Well done with your efforts - it looks promising.  If I run into problems with SA, I'll certainly give it a try!

Thanks very much for sharing your thoughts,

John

[Marcin Nowak]

On 22 April 2016 at 02:02, <john....@gmail.com> wrote:

Yeah, good call perhaps.  We're certainly drawn to raw sql (which we all know fairly well) compared to learning Django's tricks for complex queries, but the originator of our project chose to write lots of unit tests using sqlite (instead of our production mysql) for speed and simplicity reasons (notwithstanding questions of incompatibility) - so an ORM offers some extra value currently due to SQL differences that can be handled automatically.  On first glance SA appears a little more like SQL than Django's query language - though I'm sure there's times when I may tear my hair out wanting raw SQL.

If may suggest something.. sqllite with :inmemory: backend will improve speed of tests, indeed, but you will be still limited in expressing yourself because of dialect differences. You will need to "speak" using "common words" and drop away power of the specific database engine. SQLAlchemy has a marvelous expressions API, it covers more features than Django, but also it allows to build queries with direct embedding SQL literals and even parts of the query (`sqlalchemy.text()`). So it is a matter of time when your queries will become dialect-specific. Or your unit tests will block you get the things done...

In my tests I'm using many database engines. Many of tests are non-transactional, i.e. using django.test.TestCase as a base class (where every test starts with `BEGIN` and ends with `ROLLBACK`). And the most time-consuming operations are cleaning databases and loading fixtures for every test. So I removed them by overridng some of Django`s methods. I'm using factories instead of fixtures and ROLLBACK-ing after every test to avoid slow cleaning. As a result test suites are running quite fast without switching to SQLite, so I don't have to wrap everything into ORM and I can use specific features of each db.

Kind Regards,

Marcin

[Robert F.]

I know this is an old topic but I completely agree with Frank.  Nothing gives me more headaches and makes me want to move off Django more than migrations.  They seldom run smoothly and cause me no end of headaches.  I hate them!

[Tim Graham]

Perhaps giving some actionable, constructive feedback would be more useful.

[Jani Tiainen]

Hi,

We've been hitting this issue as well in our environment - so far we've been able to workaround this by using fake migrations but that is not long lasting solution.

We're using Oracle as our database backend and we have hundreds of legacy databases which aren't unified at their schema but there are some little differences here and there.

Now, when Django creates migrations it does them "wrong". Oracle doesn't have concept of transactioned DDL, but Django assumes every backend does - thus it automatically creates migrations so that it squashes all migrations done since last migration to one. And that causes the problem. With Oracle each migration should be individually runnable so if one crashes it can't leave database in unknown state.

For example if my migration adds column in tables A, B and C. If A success but B fails in Oracle it means that even migration failed A  got applied requiring manual work to also roll back manually those changes.

So, instead of Django migrations we decided to go with liquibase for database migrations since it has better workflow and concepts for migrations in Oracle.

For us this feature would be really useful, by some mean to turn off whole migration system. Personally I don't mind that if we had to do some slight extra work (like app config stuff which was proposed) to make it happen.

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a93ba892-599a-4677-9895-cb88ce36b01d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Jani Tiainen