Hi Marcin,
I originally started developing the new Django migrations as a
contrib-style app, but for reasons of complexity and maintenance, they were
best moved into the database core itself - I can describe them at length if
you like, but trust me that I tried to keep things as cleanly separable
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
On Sun, Apr 26, 2015 at 8:33 PM, Marcin Nowak
wrote:
> 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
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 d
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
wrote:
>Hi.
>Just give people possibility to disable migrations functiona
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
> ta
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, Mar
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 U
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'
>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
On Wed, Jan 22, 2014 at 9:31 PM, Hannu Krosing wrote:
>
> What about moving this kind of migration support from database driver
> to django core as an universal fallback ?
>
Definitely not! It's an awful way of doing migrations and only exists
because people use SQLite a lot for development; I'd
On 01/22/2014 08:59 AM, Shai Berger wrote:
>> This means we're really only left with:
>>> 3) The database backend or driver doesn't support altering the schema in a
>>> way that would work with Django's schema migrations API. I can't think of
>>> any that would be used with Django, but people still
On Wed, Jan 22, 2014 at 12:26 PM, Andrew Godwin wrote:
> On Wed, Jan 22, 2014 at 5:15 PM, Michael Manfre 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
On Wed, Jan 22, 2014 at 5:15 PM, Michael Manfre 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 wit
On Wednesday 22 January 2014 19:15:08 Michael Manfre wrote:
>
> I think we all agree that any database backend must continue to be able to
> create or delete schema objects, or provide something like Oracle's
> TEST_CREATE setting to allow that to be done as a non-Django step.
Actually, I don't;
On Wed, Jan 22, 2014 at 6:40 AM, 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,
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
On Wednesday 22 January 2014 16:26:50 Russell Keith-Magee wrote:
> On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger 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
2014/1/22 Michael Manfre
> Currently unknown level of effort or complexity to allow the migrations
> to fallback to a Django 1.6 syncdb-esque behavior.
>
Assuming that cost isn't too high, another concern is our ability to
maintain this feature: since none of the core backends will use it,
it ma
On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger wrote:
> Hi,
>
> (quotations reordered a little)
>
> On Wednesday 22 January 2014 14:48:25 Russell Keith-Magee wrote:
> > On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre
> wrote:
> > > *Why Disable Migrations?*
> > >
> > > 1) Not all projects need sch
Hi,
(quotations reordered a little)
On Wednesday 22 January 2014 14:48:25 Russell Keith-Magee wrote:
> On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre wrote:
> > *Why Disable Migrations?*
> >
> > 1) Not all projects need schema migrations or want Django to manage the
> > migrations. My primary
On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre wrote:
> *Must a Django Database Support Migrations?*
>
> Django 1.7 adds schema migration support and this behavior is currently
> required
> to be able to effectively use Django and run the test suite. I opened
> ticket
&
*Must a Django Database Support Migrations?*
Django 1.7 adds schema migration support and this behavior is currently
required
to be able to effectively use Django and run the test suite. I opened ticket
#21841 [1], which requests adding a DatabaseFeature to disable schema
migrations. This ticket
23 matches
Mail list logo
