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
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
>
> 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
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,
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
> 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
>
> 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
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
>
> 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
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
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
11 matches
Mail list logo
