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):
> You feel strongly against this code as it subverts the whole idea behind
> migrations.
No, it only subverts the validation of conflicts introduced by parallel lines
of development. Essentially the same concern as you attributed (correctly) to
Markus and myself together.
> However you would enjoy this feature if it was called "project migrations"
> instead and, maybe, eventually, (if I understand the name of the feature
> correctly) if the feature was automated rather than manual (project
> migrations created directly inside the project instead of having to move
> them yourself and add the extra line in it)
>
Naming is important, but there's a little more to that too: Current
migrations, and you do not propose to change that, are managed as if each only
affects its own app. Project migrations would have tooling around them --
generation, validation and execution -- that takes into account that they
affect more.
>
> Shai and Markus:
> You are both very concerned about multiple leaf migration trees and about
> the fact that those leaf migrations might clash with each other.
> After deeper thinking, this concern is probably more than legitimate but
> has, also probably, very little to do with the current proposal. If running
> makemigrations creates a new migration for an app you didn't write, it will
> end-up being a leaf migration independent of whether you leave it in your
> venv or are able to move it to your project and exposes you to the "clash"
> risks all the same.
>
... except that when all the migrations are in the same app, DJango already
has mechanisms to detect and warn users against these clashes. True, the tools
are blunt and require the user to make the decision about actual clash-or-no-
clash, with almost no aid beyond pointing out the possibility of the clash.
But this is still a lot better than the completely silent clashes your
suggestion enables.
>
> About modeltranslation:
> I, personally, am not too found of apps using contribute_to_class either so
> if anyone knows of an app which allows me to have translations for
> user-generated content living in my database (as those are translations for
> content from the database) which is pluggable on third party apps and
> doesn't require an extra join on (almost) every query, please let me know,
I'm not sure if it works with modern Django -- last time I looked it was
updated to Django 1.2, and I haven't had to deal with translations in the
database for several years now -- but I always thought django-dbgettext had it
right. Its strategy was to pull specified database strings into .po files so
you
can translate them just like you translate strings from your source.
(Oh, upon looking I see that it did get some attention last year. Good).
HTH,
Shai.
