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