refactor models/__init__.py so fields themselves add their own get_XXXX_count/list functions

[Ian@…]

currently in models/__init__.py there is a big for loop which goes over all the installed modules
and creates the foreign key relationships (oneTomany,manytomany and one to one) with a big if/else/elif statement.

I propose we move the if/elif logic to the actual field code itself. so a field 'knows' what functions it has to create, and field writers could override this functionality to add their own relationships if they choose

from

for related in klass._meta.get_all_related_objects():
 if foo:
   ....
 elsif blah:
   ....

to

 for related in klass._meta.get_all_related_objects():
    related.create_relationships( klass, meta )

and

class OneToOne:
  def create_relationships( klass,meta )
    func = curry(....)
    ...
    klass.setattr(...)

I think this change would be backwards compatible. and could allow me to define a 'TagField' which creates special functions.

[ian@…]

Meta Model Patch

[ian@…]

or is it better to actually have this function on the XXXField instead of XXX ?

[ian@…]

now hangs of the fields instead

[rjwittams]

This patch is against the new-admin branch, its probably worth mentioning that.
In its current form it has no chance of working with trunk. Its almost certainly not worth backporting to trunk, either it should get applied in new-admin, or applied after new-admin merges.

This is something I had a comment about doing in new-admin so I'll have a look at it and see if it is backwards compatible.

[anonymous]

Ok, it looks ok-ish so far. I'd prefer it if the scope was expanded to cover all field-provided methods, not just the relationship ones, eg date, choice, image,file methods. Passing "meta" as an argument seems odd as well, this is just a module, right? The functions to be curried and stuffed onto the class and module should be in fields.py, perhaps as staticmethods of the field classes.

So setup_relationships is probably a misnomer - I think we need something like "mutate_module" for adding module functions, and "mutate_class" for instance methods. You'll need to look at all the places the class and module are added to work out the appropriate arguments for these functions.

[ian@…]

If you can point me to where they are defined now that would be great.

the meta is passed as an argument, as I couldn't figure out a way to reference it without passing it (I'm a python newbie, so it might be blantantly obvious)

I'm not sure why we need to seperate functions (one for class methods, and the other for instance methods).

maybe setup_field_functions?

regards
Ian
ps.. the code works as-is in my apps.

[rjwittams]

So there are two things that a field might want to contribute methods to :

• The magic model module
• The generated model class

So I thought it would make sense to do this in two functions.
The functions are defined at the moment in django/core/meta/__init__.py

So the idea is it would just loop over all the fields, asking for their contribution to the class and the module (this might need to be done in two loops or something).
So maybe the methods should be called 'contribute_to_class', and 'contribute_to_module'.

I'm not sure about the ordering here, at the moment the relationship related methods are setup here, and everything else is setup in the metaclass. So I guess this needs a bit of thought.

So the meta : it looks like the only reason you need this is to access the curried functions - these should probably become static methods of the field or something. Other than that, just import django.core.meta, or the individual functions from there.

I might have a better look into this tomorrow.

[rjwittams]

Ok, so this is included in my mutually referential models svk branch. I will make a ticket for that soon and upload a patch. If not, bug me.

[Adrian Holovaty]

Closing this, as it's out of date for magic-removal.