Hi Marcin,
On 12/22/2014 10:28 AM, Marcin Nowak wrote:
>> This is not an optional contrib add-on, it's a core part of the ORM.
>
> There are systems where Django is not a core, but it is used as lightweight
> app server.
> Database schema migrations are created and executed in the other way..
>
> This is not an optional contrib add-on, it's a core part of the ORM.
>
There are systems where Django is not a core, but it is used as lightweight
app server.
Database schema migrations are created and executed in the other way..
That's why is so important to not change any database schem
Hi All,
Totally a shot in the dark here, but would allow_migrate work in this case?
https://docs.djangoproject.com/en/dev/topics/db/multi-db/#allow_migrate
Collin
On Friday, December 19, 2014 2:04:37 PM UTC-5, Carl Meyer wrote:
>
> On 12/19/2014 11:59 AM, Marcin Nowak wrote:
> >
> >
> > On F
On 12/19/2014 11:59 AM, Marcin Nowak wrote:
>
>
> On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote:
>>
>>
>> As far as I understood, Marcin wants to treat *all* models as unmanaged;
>> there
>> are no managed models to reference the unmanaged ones.
>>
>
> I would like to disa
On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote:
>
>
> As far as I understood, Marcin wants to treat *all* models as unmanaged;
> there
> are no managed models to reference the unmanaged ones.
>
I would like to disable/remove/kick-off built-in migration mechanism. :)
If may
Hi Markus,
On Thursday 18 December 2014 08:54:30 Markus Holtermann wrote:
>
> 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.
>
As
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, t
FWIW, the approach I would go for is to try to monkeypatch
managed=False into the base model Meta.
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 ch
On Tuesday, December 16, 2014 1:49:53 PM UTC+1, Andrew Godwin wrote:
>
>
> 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 ma
Hey Marcin, Andrew,
setting manager=False wouldn't work either, as the migrations for those
models still need to exist. I probably have references to them which makes
them a requirement for FKs in migrations. Unmanaged models behave exactly
the same as managed models in migrations, with one exc
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 curre
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.
Th
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
wrote:
>
> Hello!
>
> I'm using
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 schem
14 matches
Mail list logo
