#14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples
for
generic relations.
-----------------------------------------+----------------------------------
Reporter: mrmachine | Owner:
Status: new | Milestone: 1.3
Component: Documentation | Version: SVN
Resolution: | Keywords: generic relation
genericforeignkey object_id type textfield sprintdec2010
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
-----------------------------------------+----------------------------------
Comment (by PaulM):
This really is a bit of a sticky issue.
In the vast majority of cases, `PositiveIntegerField` is the correct
choice `[1]`. In particular, it's going to be faster, support indexing,
and generally use less memory.
`TextField` is really the wrong choice most of the time. Most backends
implement it using "blob" storage or similar, which uses significantly
more memory for smaller items, doesn't support efficient indexing, and is
almost always less performant than the other options.
`CharField` is an interesting compromise. It is much closer to
`(Positive)IntegerField` in terms of performance, but again, this varies
on a backend basis. More problematically, it requires a specified length,
which is going to vary significantly depending on the ID scheme in use. If
we pick a "safe" recommended value of say, 128 characters, we waste
significant database space on some backends, especially if the actual
addressing scheme in use is a monotonically increasing positive integer
(and we still don't support users who, for whatever reason, want to use
129 character values).
I agree that encouraging third-party developers to build reusable
applications which will work across a broad variety of databases is a very
good goal. In particular, as Django becomes easier to use with non-
traditional databases, this sort of RDBMS-centric thinking will crop up
more often. However, in this case I think that leaving the example with a
`PositiveIntegerField` is probably the best option. It encourages new
developers toward the choice which will be most performant (and
compatible) in the current majority of cases. I also strongly support the
addition of the pullout highlighting the issue, but cannot endorse
generically recommending a `Text` or `CharField` in all situations.
I'd like to hear Alex Gaynor's thoughts on this issue.
`[1]` because on some backends, `IntegerField` actually is signed (not
just checked in Django), and negative values are not a standard usage
here.
--
Ticket URL: <http://code.djangoproject.com/ticket/14820#comment:11>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
