On Fri, Nov 27, 2009 at 4:21 PM, Mario Briggs <mario.bri...@in.ibm.com> wrote: > Russ, > >> With a different coat of paint, it might be more palatable. A name >> like ShortTextField presupposes the storage implementation, but tells >> you nothing about the appropriate usage. However, a different name - >> something like GenericKeyField tells you nothing about the storage, >> but does tell you when it might be appropriate to use it. >> > > GenericKeyField - Its hard for me to see that a end-user would not be > interested in the specific type of his column at the database > especially if its a key field.
Depends on the focus of the developer. DB-focussed developers or developers looking to optimize query performance might care about the underlying storage. However, developers working at a higher level just want their data to be stored. The exact database type is irrelevant as long as queries using that field work in reasonable time. Django currently uses a TextField is currently storing a string-serialized form of the key of an arbitrary object. What is being stored in any given row can be determined by looking at the content_type of the row (or rather, the primary key type of the model that the content type refers to). It is used to create log entries that point at arbitrary objects in the database. From a pure DBA, third-normal-form perspective, it isn't an especially efficient data structure - but it *works* for the situation in which it used. At the end of the day, that's what really matters. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
