Hey Shai,
manage=False won't gain you anything, since those models will still show
up in migrations, because they need to be able to be referenced by
managed models. The migration database operations are noops though.
/Markus
On Thu, Dec 18, 2014 at 06:08:52AM +0200, Shai Berger wrote:
FWIW, the approach I would go for is to <handwaving>try to monkeypatch
managed=False into the base model Meta</handwaving>.
Shai.
On Tuesday 16 December 2014 14:49:25 Andrew Godwin wrote:
Hi Marcin,
You can't bypass migrations as much as you can't bypass syncdb; that is,
the commands are separate and you can choose not to run them (or just
delete the migration files). As far as I can tell your only issue is the
runserver warning that you have unmigrated changes, which there's currently
no plan to be able to disable.
Also bear in mind that, by doing your own schema management for the contrib
apps, you're kind of implicitly forking the schema; Django 1.8 will ship
with some migrations for these apps, and you're going to have to make sure
you manage those yourself and keep the database in sync with the code
(though of course the release notes will mention this kind of thing).
If you want to stub out migration operations, you can just make a custom
database backend that inherits from the one you use and define a new
SchemaEditor subclass with an execute() function that does nothing; that
should accomplish what you want. Alternatively, you could wrap all
migration operations into the State side of SeparateDatabaseAndState, but
that's a bit cumbersome.
Andrew
On Tue, Dec 16, 2014 at 4:42 AM, Marcin Nowak <marcin.j.no...@gmail.com>
wrote:
> Hi Andrew,
>
> Thanks for a reply. But as I've mentioned above I can't set managed=False
> on models delivered from external apps like django.contrib.auth,
> django.contrib.sessions, and many more. Forking them is not an option.
>
> I think that bypassing migrations should be possible via some setting.
> That's why I wrote to developers forum directly.
> Please think about that.
>
> Marcin
>
> On Tuesday, December 16, 2014 1:34:17 PM UTC+1, Andrew Godwin wrote:
>> Hi Marcin,
>>
>> If you're using an external tool to manage schemas of models, just set
>> managed=False on the models and Django will stop trying to change their
>> schemas (including stopping making migrations for them).
>>
>> Andrew
>>
>> On Tue, Dec 16, 2014 at 1:11 AM, Marcin Nowak <marcin....@gmail.com>
>>
>> wrote:
>>> Hello!
>>>
>>> I'm using Django as a part of bigger stack where I'm using external
>>> tool to manage database migrations.
>>> After migration to Django 1.7 I'm encouraged at every runserver command
>>> to execute some migrations, which may blow my databases.
>>>
>>> I want to bypass Django migrations to prevent any schema modification.
>>> I can bypass migrate* commands by overriding them in my custom app,
>>> but this is a little tricky and does not cover all cases. Using
>>> managed=False is not a solution, because none of reusable apps have
>>> models defined as unmanaged (same for django.contrib, especially auth
>>> and sessions).
>>> That's why I need to bypass migrations globally.
>>>
>>> Have you ever considered possibility to allow disabling it? Maybe via
>>> some setting to use kind a DummyMigrationExecutor instead of
>>> MigrationExecutor?
>>>
>>> Cheers,
>>> Marcin
>>>
>>> --
>>>
>>> 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 django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/a27293a1-4212-4a2a-ae44-
>>> 4720fc674162%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/a27293a1-4212-4a2a
>>> -ae44-4720fc674162%40googlegroups.com?utm_medium=email&utm_source=foote
>>> r> .
>>> 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 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/d8226a81-9dfe-4019-94
> ce-98beb6e1bf04%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/d8226a81-9dfe-4019-
> 94ce-98beb6e1bf04%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 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/20141218065430.GE17486%40pyler.local.
For more options, visit https://groups.google.com/d/optout.
