#20113 closed Cleanup/optimization (duplicate)
Documentation on _ptr and _ptr_id use in multi-table inheritance
Reported by: | anonymous | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The documentation on "Multi-table inheritance" does not mention the naming of the (generated) primary / foreign key field of the inheriting table (which becomes place_ptr_id in the Place / Restaurant example).
If I use instance data from that model in a template, and want to render the fields myself, I need that name, as described in "Using the formset in the template":
<form method="post" action=""> {{ formset.management_form }} {% for form in formset %} {{ form.place_ptr }} <ul> <li>{{ ... }}</li> </ul> {% endfor %} </form>
Confusingly, the name which should be used here is "place_ptr", not "place_ptr_id", which it is in the database (using "place_ptr_id" in the template gives a MultiValueDictKeyError). Since this is not documented (or I haven't found it, though I did search!), I suggest adding something to the "Multi-table inheritance" documentation which explains how the auto-generated field can be used in templates as "place_ptr".
Change History (3)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:3 by , 9 years ago
Component: | Uncategorized → Documentation |
---|---|
Description: | modified (diff) |
Type: | Uncategorized → Cleanup/optimization |
Duplicate of #11097