Apologies if I'm misunderstanding the issue, but wouldn't something like
%(app_label)s and/or %(class_name)s solve this issue, as suggested in the
Models docs[1] regarding abstract classes?

Cheers,
AT

[1]
https://docs.djangoproject.com/en/dev/topics/db/models/#abstract-related-name


On Thu, Jan 2, 2014 at 10:55 AM, Marc Tamlyn <[email protected]> wrote:

> The changes wouldn't directly address this issue - and if you're in
> control of both apps it's not really a big deal anyway. But supposing this
> happened in two third party apps, then it *may* be possible to create a
> custom AppConfig for one of them and change the related_name on one of the
> models in the ready() method. However, this would involve messing around
> with the internal implementation of model classes to find the right label
> to change as dynamically altering models is not currently supported.
> Depending on where the check happens, it might not work anyway.
>
> Marc
>
>
> On 2 January 2014 12:44, joseph brown <[email protected]> wrote:
>
>>  Aymeric Augustin 
>> <[email protected]><[email protected]>Jan 
>> 01 09:46PM +0100
>>
>>
>>    1) Allow apps without a models module or package
>>    2) Provide verbose_name for the admin
>>    3) Provide a reliable initialization signal
>>    4) Allow changing app_label in case of name clashes
>>    6) Clarify the app cache population sequence
>>    7) Enforce consistency between the contents of INSTALLED_APPS and the
>>    AppCache
>>    11) Order of INSTALLED_APPS — #21018
>>
>>  I'm impressed.  Sounds like a lot of work to me, which will pay off for
>> the community at large.
>>
>> One question, probably belongs on django users:
>>
>> background:
>>
>> Recently discovered the same two tables in different apps clash.  Didn't
>> take long to figure it out because I copied one app from the other.  Had I
>> inadvertently named the tables the same and both had foreign keys to User,
>> the related_name had to be set for one or both.  Not a big deal, but the
>> error wouldn't have made sense, had I not been aware.
>>
>> question:
>>
>> Will any of your changes address this issue?
>>
>> -Joe
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/52C55F49.8060404%40gmail.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1FFo_5W1zKzsyxTS3GuVV6nZgQMRyZc2n%3Duoho%3DuHkrhg%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKBiv3zSHHpMDqnFfVauJa5VbX3cLQQ0CfUjECEdH%2Bkr2Xk3LQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to