Opened 17 years ago

Closed 16 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: dev
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

Description

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@…> 17 years ago.
generic.py patch and generic relations doc test

Download all attachments as: .zip

Change History (6)

by kgoudeaux <kgoudeaux@…>, 17 years ago

Attachment: generic.diff added

generic.py patch and generic relations doc test

comment:1 by Jacob, 17 years ago

Resolution: wontfix
Status: newclosed

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

comment:2 by kgoudeaux@…, 17 years ago

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 by Koen Biermans <koen.biermans@…>, 17 years ago

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 by Jacob, 16 years ago

Triage Stage: UnreviewedDesign decision needed

comment:5 by Koen Biermans <koen.biermans@…>, 16 years ago

Resolution: fixed
Status: reopenedclosed

It seems this was fixed in r9562.

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