Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
Hi, I've added a ticket with a patch for automatically discovering models within a package without using the app_label Meta attribute. An old and somewhat related ticket is: http://code.djangoproject.com/ticket/2289/. This addition is relatively small code-wise, but it does add a new feature to the framework. Instead of "looking one level up" from the module a model is defined in the new code looks one level up from the module/package named "models" and then falls back to the existing behavior of simply "looking one level up" if no such module/package exists. I've added examples of the new functionality to the existing comments in the code: For 'django.contrib.sites.models', one level up would be 'sites'. For 'geo.models.places' it would be 'geo'. For 'polymorphic.polymorhpic_model' it would be 'polymorphic'. I've also copied and slightly modified the existing model_package model tests to cover the new code. This addition is very intuitive IMO, and it definitely cuts down on the overhead incurred when making the design decision to group models into a package. I certainly find it useful. Per the Django contributor guidelines I'm asking for guidance about whether this patch is considered non-trivial. Any feedback is appreciated. Thanks, - Mark http://code.djangoproject.com/ticket/14007 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
Hi, The process of model discovery is not modified by this patch. Continue reading for more details. - Mark polymorphic is an interesting case, as it only defines one model and that model is abstract. Therefore polymorphic doesn't need to be in INSTALLED_APPS (and perhaps my example is therefore dumb). The way Django currently works (in django.db.models.base.ModelBase) is that the app_label for a model is determined by "looking one level" up from the module the model is *defined* in. This has the interesting effect that models are discovered by the mere fact of importing them; they don't need to be defined in a module named models. Currently when PolymorphicModel is imported from polymorphic (either by writing "from polymorphic import PolymorphicModel" or "from polymorphic.polymorphic_model import PolymorphicModel"; the class is available in both modules), the app_label is determined to be "polymorphic" since "polymorphic" is one level up from "polymorphic_model" in "polymorphic.polymorphic_model", which is the module PolymorphicModel is actually defined in. My patch mimics this behavior. As another example, consider a model defined in myapp.tests (this is done in the tests provided with the patch). Models in myapp.tests are discovered since myapp.tests is imported when running tests. app_label is determined to be "myapp" in this case since "myapp" is one level up from tests in "myapp.tests". Now consider a model defined in myapp.models.some_models. app_label would currently be determined to be "models" since "models" is one level up from "some_models" in "myapp.models.some_models". This is not the desired behavior, so a Meta class must be defined with the attribute app_label = "myapp" to rectify the situation. My patch makes is so that Django looks one level up from the last occurrence of "models", if present. app_label then doesn't need to be explicitly specified for every model when factoring a app's models module into sub modules. What's strange about all this is that if you currently (and with my patch) define a model in myapp.package.other_models and other_models gets imported, then SomeModel in other_models will have the bogus app_label "package" since "package" is one level up from "other_models" in "myapp.package.other_models". This turns out to be harmless most of the time since sql isn't generated for apps that aren't in INSTALLED_APPS (although you're in trouble if you actually try to use a model with a bogus app_label). The one freaky case is when you actually have an app named "package", in which case sql will be generated for the bogus models as well as the expected models. This strangeness is present is Django currently, and my patch doesn't fix of modify this behavior. - Mark On Wed, Jul 28, 2010 at 9:46 AM, burc...@gmail.com wrote: > Hi Mark, > > > For 'polymorphic.polymorphic_model' it would be 'polymorphic'. > Is that correct this didn't work at all (or didn't work properly) > before your patch, and now works properly, so one can put > "polymorphic.polymorphic_model" into their INSTALLED_APPS and > everything would work? > Should one import polymorphic_model from polymorphic.__init__ and put > "polymorphic" into INSTALLED_APPS? > Should one import polymorphic_model from polymorphic.models and put > "polymorphic" into INSTALLED_APPS? > > In few words, how does the models discovery work for this case with your > patch? > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute
Hi Jacob, Rajeev pinpointed the use case. The company I work for has a large bit of infrastructure built around Django. Our main project consists of 6 apps, each of which has a defined role (with respect to the other apps). One of our apps has quite a few models and quite a bit a logic around those models. The source is over 3000 lines. This amount of code is obviously difficult to manage in one file; one file per model and supporting models (gerunds, etc) would be ideal. In certain cases I believe developers would find this patch very useful, and very little is added to achieve this additional functionality. Looking at the issue from a broader perspective, I believe people expect to be able to convert Python modules into packages. This was certainly my expectation the first time I tried to factor a models module. - Mark On Wed, Jul 28, 2010 at 10:55 AM, Rajeev J Sebastian < rajeev.sebast...@gmail.com> wrote: > On Wed, Jul 28, 2010 at 10:45 PM, Jacob Kaplan-Moss > wrote: > > On Wed, Jul 28, 2010 at 12:09 PM, Rajeev J Sebastian > > wrote: > >> I think it might be useful for people refactoring their ever-growing > models.py > > > > That's maybe part of what I don't understand: I can't ever say I've > > seen a models.py so big that I felt the need to split it up. Or > > rather, I have, but in each case it was better design to break up the > > entire app into a few smaller ones. > > > > I just don't see a problem that, in the very rare case you *do* have a > > models.py that needs to be broken up, you have to manually specify > > app_label. > > I guess thats a different way of working, where you have a lot of smaller > apps. > > It's just boring to repeat the same thing all over the code :D > > Regards > Rajeev J Sebastian > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
