Opened 10 years ago
Last modified 7 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))
.