Opened 11 years ago

Closed 10 years ago

#5826 closed (fixed)

Can't recover GenericForeignKey content type and object id field names

Reported by: kgoudeaux Owned by: nobody
Component: Contrib apps Version: master
Severity: Keywords: ContentType GenericForeignKey generic relations
Cc: koen.biermans@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The GenericForeignKey class is perfect for recovering the object it references but leaves no way to recover itself and the field names it stores.

Its get function only returns the object it references or an error.
DoesNotExist when it isn't set on an instance.
AttributeError when accessed from the model class.

This one line patch and doc test changes the behavior of get to return the GenericForeignKey instance when accessed from the model class thereby allowing access to the content type and primary key field names.

Attachments (1)

generic.diff (1.2 KB) - added by kgoudeaux <kgoudeaux@…> 11 years ago. patch and generic relations doc test

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by kgoudeaux <kgoudeaux@…>

Attachment: generic.diff added patch and generic relations doc test

comment:1 Changed 11 years ago by Jacob

Resolution: wontfix
Status: newclosed

You need to go through Model._meta.fields to get at this info.

comment:2 Changed 11 years ago by kgoudeaux@…

Resolution: wontfix
Status: closedreopened

The information for each field is in Meta, of course, but there is no way to determine which fields correspond with what for a generic foreign key.
You can guess 'content_type' and 'object_id' but this won't always be the case.

It seems reasonable that GenericForeignKey would allow some way to programmatically determine which fields in Meta that it references when interacting with the Class, as opposed to an instance.

comment:3 Changed 11 years ago by Koen Biermans <koen.biermans@…>

Cc: koen.biermans@… added

I just tried this to make auditTrail (as described in the wiki) also provide the genericforeign key on the original item. Works perfectly.
Definitely a good change.

comment:4 Changed 11 years ago by Jacob

Triage Stage: UnreviewedDesign decision needed

comment:5 Changed 10 years ago by Koen Biermans <koen.biermans@…>

Resolution: fixed
Status: reopenedclosed

It seems this was fixed in r9562.

Note: See TracTickets for help on using tickets.
Back to Top