On Apr 7, 2010, at 1:40 PM, Russell Keith-Magee wrote:
> On Mon, Apr 5, 2010 at 5:35 AM, Arthur Koziel <art...@arthurkoziel.com> wrote:
>> Hi,
>> I’m going to apply for GSoC with the goal of refactoring the app loading
>> [0]. I’ve been looking at Django’s current app loading implementation
>> (db.models.loading), Vinay Sajip’s patch in #3591 [1] and the notes on the
>> InstalledAppsRevision wiki page [2]. Here's what I'm planning to change. Any
>> feedback is appreciated.
>> Step 1
>> ---------
>> Deal with the two main problems of the current app loading implementation,
>> and make it possible to:
>> - deploy several instances of the same app
>> - deploy two apps with the same name
>> The INSTALLED_APPS setting will be changed to:
>>
>> INSTALLED_APPS = InstalledApps(
>> 'django.contrib.auth', # strings will be converted to App()
>
> Strings will be converted to App()... by What? When?
>
The InstalledApps() class will do the converting during the initialization. As
Vinay mentioned, his patch already does this in line 157.
> What happens to existing code that is using "for app in INSTALLED_APS"
> as an idiom?
That's the main reason why INSTALLED_APPS will be an InstalledApps instance.
This way, an __iter__ function could be added that goes through an internal
dict of Apps and yields their module path as a string.
>
>> App('django.contrib.contenttypes'),
>> App('django.contrib.sessions'),
>> App('django.contrib.sites'),
>> App('django.contrib.messages'),
>> App('django.contrib.admin'),
>> App('django.contrib.admin', name=‘demo’),
>> )
>>
>> The InstalledApps and App classes will be added to core.apps. The
>> db.models.loading module will be deprecated and redirect to core.apps.
>
> Is there a specific reason for this move? Is it just shuffling
> deckchairs, or is there a purpose behind the move?
Yes, I wanted to make it optional for Apps to have models associated. And if an
App doesn't require models, what's the point of it to live in db.models?
>
>> The structure of the InstalledApps class will be similiar to the
>> db.models.loading.AppCache class. Instead of storing the model
>> modules/instances for each app (app_store/app_models), this class will store
>> the App instances. An App instance will store the model modules/instances.
>> The methods of the old AppCache class (get_apps(), get_app(), ...) will be
>> kept for backwards compatibility but modified to reflect the change
>> mentioned above.
>> Step 2
>> ---------
>> As mentioned on the InstalledAppsRevision wiki page [2],
>> model._meta.app_label is overloaded and used for:
>>
>> - Admin app display name (by .title())
>> - Admin permissions prefix
>> - DB table creation prefix
>> - Dumpdata/Loaddata fixture prefix identifier
>> - When explicitly set, used to associate models elsewhere in the app
>> structure.
>> - RelatedObject explicit cross-app identification.
>> - contrib.contenttypes identification
>>
>> The goals of Step 2 is to add options to the App class and modify other
>> parts of Django to not rely so heavily on app_label. For example, a
>> `db_prefix` option could be added to the App class and the ORM code could be
>> modified to use db_prefix instead of app_label:
>>
>> INSTALLED_APPS = InstalledApps(
>> App('django.contrib.admin', db_prefix='chewie'),
>> )
>>
>> In order for this to work, each model instance needs to have an app instance
>> associated (via _meta.app). The orm code can then use
>> model._meta.app.db_prefix to create the table.
>
> I agree with Alex - there's a lot more detail needed here. How will I
> get access to the App instance that a model belongs to? How will
> legacy attributes like db_prefix be proxied? What is the order of
> precedence when a model and an app disagree on db_prefix?
>
> For the record - I don't think the "multiple versions of a single app"
> problem is one worth solving. I'm not even convinced it can be solved
> at all, for all the reasons Florian identified, and then some.
> Although it may have been part of the original use case for #3591,
> much of that use case has since been replaced by namespaced URLs and
> class-based applications. If you're going to tackle this problem, I'd
> rather see you concentrate on issues like:
>
> * Translating application names
> * Solving the "two applications called auth" problem
> * Providing configurability for db-level naming convention at the
> deployment level (e.g., so you can override db_prefix and table names
> when you deploy an app)
> * Providing configurability for 'app level' settings; for example,
> when deploying contrib.comments, setting the name of the model that
> will be used for content.
Okay, I'll focus on these issues rather than multiple app instances.
>
>> Step 3
>> ---------
>> The current app loading implementation in Django was designed to load model
>> classes. However, there are many applications which just provide
>> templatetags or management commands and don’t use Django’s ORM at all. These
>> applications have to ship with an empty models.py file in order to be loaded
>> correctly. The goal of Step 3 is to make it possible to load applications
>> without a models.py file.
>
> I would have thought this step would have been a logical consequence
> of Step 1; if you're going to massively rewrite app loading, it would
> seem unusual to embed all the old problems in your rewrite.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.
