Hi,
On Thursday 10 September 2015 17:00:07 Emmanuelle Delescolle wrote:
> As this thread is most likely leading to a dead-end, let me try to close it
> by summarizing it:
Not trying to re-open the thread, just that...
>
> Shai:
This seemed a little far from what I said (or, at least, intended)
As this thread is most likely leading to a dead-end, let me try to close it
by summarizing it:
Original proposal:
- adding a property to the current migration class to make it more
extendable
Idea behind the proposal:
- being able to move the migrations generated in my venv when running
makemi
On Wednesday 09 September 2015 16:35:16 Markus Holtermann wrote:
> On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote:
> > On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek > >
> > >The order of migrations within a single app is fixed.
> >
> > No, actually it isn't. It is
On Wednesday, September 9, 2015 at 9:21:43 PM UTC+10, Shai Berger wrote:
>
>
>
> On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek > wrote:
> >
> >>
> >> The order of migrations isn't something which is local to this
> >feature, it
> >> is something which isn't fixed (probably by design,
On 9 בספטמבר 2015 13:29:58 GMT+03:00, Marten Kenbeek
wrote:
>
>>
>> The order of migrations isn't something which is local to this
>feature, it
>> is something which isn't fixed (probably by design, correct me if I'm
>
>> wrong) and if it is not "the right way" to do it, maybe it should be
>pa
On Wednesday, 9 September 2015 12:29:59 UTC+2, Marten Kenbeek wrote:
>
> The order of migrations isn't something which is local to this feature, it
>> is something which isn't fixed (probably by design, correct me if I'm
>> wrong) and if it is not "the right way" to do it, maybe it should be pa
>
> The order of migrations isn't something which is local to this feature, it
> is something which isn't fixed (probably by design, correct me if I'm
> wrong) and if it is not "the right way" to do it, maybe it should be part
> of another issue.
The order of migrations within a single app is
>
> if we change the code in Django that does order resolution even slightly
> it could result in different operation orders or even different "final"
> rendered models.
The order of migrations isn't something which is local to this feature, it
is something which isn't fixed (probably by desi
Say A.0002 and B.0001 are different leaf nodes for A.0001, and both alter
the same field.
Now, on a clean database, the order is pretty stable. If that order is
A.0001, A.0002, B.0001,
you'll always end up with the field from B.0001. This is also what the
autodetector sees.
If you first creat
I still feel like merge migrations are necessary, if not only because
they're a way of reducing the potential collision area of migration
ordering from different branches, but it might be that the solver is
predictable enough that it's not a problem. Two separate branches in
migrations still don't
Ok, two things:
1) Markus' idea of having more than one folder for migration modules seems
reasonable enough. I disagree with his comment about the placement of merge
migrations --
> Django needs to know where to
> place the merge-migration. I'd go with the first item in the list
I'd require
Hi Emmanuelle,
I think the main problem is the dependencies between migrations. The order
in which migrations
are run is not fixed. It depends on which migrations have already run, and
we can't guarantee the
same order for each deployment. If each chain of migrations that could act
on a singl
On Friday, 4 September 2015 00:29:28 UTC+2, Shai Berger wrote:
>
> What Markus (and myself) assumed is that when you add the "migrated_app"
> attribute, you make the migration belong to the migrated app. What you did
> is
> different: The migration still belongs to the app it is defined in, it
Hi,
On Thursday 03 September 2015 12:44:08 Emmanuelle Delescolle wrote:
[Markus Holtermann wrote:]
> > But as Andrew already said, you *will have* problems when you have your
> > own migrations and a third party app adds a new one. Suddenly there are
> > two leafs which is an invalid state. You w
First of all, I have to appologize, I just noticed that the sample
application repository was missing some files (the models which is a shame
for a sample app demonstrating migrations) which made the app useless. This
has been fixed.
However, I strongly agree with Andrew that, if we allow this
Thank you for your patches and ideas of how to solve this feature,
Emmanuelle.
However, I strongly agree with Andrew that, if we allow this -- I'm on
Tim's side here, it feels odd encouriging something that's not considered
to be used for that purpose: `contribute_to_class` -- the solution shou
> My main concern is not with the complexity of your proposed patch but with
> committing to supporting a new API that solves a problem that can already
> be solved a different way (albeit maybe less elegantly). Anyway, I don't
> want to speak definitely about the issue, but it seems like if w
My main concern is not with the complexity of your proposed patch but with
committing to supporting a new API that solves a problem that can already
be solved a different way (albeit maybe less elegantly). Anyway, I don't
want to speak definitely about the issue, but it seems like if we keep
th
>
> I think if I were doing this, I would go the route of using
> MIGRATION_MODULES and copying the reusable app's migrations into it, then
> adding my own migrations. Yes, this would require copying any new
> migrations from an updated version of the app,
>
Yes that sounds like a lot of work
I think if I were doing this, I would go the route of using
MIGRATION_MODULES and copying the reusable app's migrations into it, then
adding my own migrations. Yes, this would require copying any new
migrations from an updated version of the app, but I am a bit nervous about
adding more complex
Quote from Russ Magee's Twitter
> Django 1.9 is coming - do you have something on your wishlist? DSF Fellow
> Tim Graham has an offer for you: groups.google.com/d/msgid/django…
Well, actually, I'd really like this for 1.9 ;-)
Has anyone +1's for this or is it more like -1's ?
> Sample proj
>
> The main problem I see with this is that it allows one app to mess with
> other
> apps' models (yes, it means I think modeltranslations is Doing It
> Wrong(tm),
> and the current issue is just pointing that out more loudly).
I agree that allowing apps to mess with other apps' models mig
On Mon, Aug 24, 2015 at 10:19 PM, Emmanuelle Delescolle <
delesco...@gmail.com> wrote:
> I've been using this solution on a couple projects (including ones with
> several children to the same migration) and have never had troubles with
> the migration solver, I guess I have been lucky.
>
> I'll th
On Tuesday 25 August 2015 05:13:14 Andrew Godwin wrote:
> The main problem I forsee here is just making sure that the MigrationLoader
> knows to take these located-in-the-wrong-place migrations and insert them
> into the migration tree right - in particular, you have issues with the
> dependencies,
I've been using this solution on a couple projects (including ones with
several children to the same migration) and have never had troubles with
the migration solver, I guess I have been lucky.
I'll throw a sample application today and try to reproduce the problem and
see how it can be fixed/wo
The main problem I forsee here is just making sure that the MigrationLoader
knows to take these located-in-the-wrong-place migrations and insert them
into the migration tree right - in particular, you have issues with the
dependencies, because say you made a third-party migration that depends on
ap
Hi everyone,
I'd like to talk about giving the ability to migrate models from other
applications and I am addressing this mailing list as suggested by Tim
Graham (https://code.djangoproject.com/ticket/25288).
Although I think this might be dangerous if mis-used, this is not the first
time I co
27 matches
Mail list logo