Re: Digest for django-developers@googlegroups.com - 1 Message in 1 Topic

72 views
Skip to first unread message

joseph brown

unread,
Jan 2, 2014, 7:44:57 AM1/2/14
to django-d...@googlegroups.com
Aymeric Augustin <aymeric....@polytechnique.org> 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

Marc Tamlyn

unread,
Jan 2, 2014, 7:55:24 AM1/2/14
to django-d...@googlegroups.com
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 <1st...@gmail.com> wrote:
Aymeric Augustin <aymeric....@polytechnique.org> 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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.

Andre Terra

unread,
Jan 2, 2014, 3:43:29 PM1/2/14
to django-d...@googlegroups.com
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



Reply all
Reply to author
Forward
0 new messages