Opened 11 years ago
Last modified 8 years ago
#24201 closed New feature
order_with_respect_to GenericForeignKey — at Initial Version
| Reported by: | Alex Hill | Owned by: | nobody |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
As of 1.8, order_with_respect_to nearly works with generic relations.
First thing that's broken is the get_RELATED_order and set_RELATED_order methods. They are set in ModelBase._prepare. You don't know what model is going to be on the other end of the GenericForeignKey, so I think those can simply be omitted if opts.order_with_respect_to.rel is None. (Perhaps something can be done here in cases where a GenericRelation is defined.)
Next, you run into trouble when Django tries to save a new object's _order field, because there's no attname attribute on the GenericForeignKey. You run into the same problem in _get_next_or_previous_in_order().
This is easily solved if you're OK with sprinkling details of the GenericForeignKey implementation in Django core: you can just try attname, and if that fails, filter on GFK's ct_field and pk_field. But maybe a better idea would be to introduce a method on field-like things returning a dictionary of filter parameters matching a given object, or else a property returning a sequence of (filter name, attribute name) pairs from which the filter parameters can be constructed. In the latter case, regular fields would return ((self.name, self.attname),), and GFKs would return ((self.fk_field, self.fk_field), (self.ct_field, self.ct_field)).