Hi Shai, On Sun, Aug 17, 2014 at 3:44 AM, Shai Berger <[email protected]> wrote:
> Hi, > > It seems to me that the taxonomy doesn't handle well FileField and > ImageField. > It could be bundled in with ForeignKey (as the data it really represents is > only pointed at by the related column data), but not with the current > wording. > > For ImageField, there is -- in addition to the above -- the relation to > height_field and width_field. It would appear to be a mix between a pure > field > and a virtual field. > I'm not sure this is a problem. I agree that conceptually, part of the data for a FileField/ImageField is held "externally"; but it's a different kind of external. From the database's perspective, the record is complete and correct when you're storing a string. The fact that the string represents a file system path is a very significant implementation detail - after all, you need to know to show a file browsing dialog (or whatever UI you want) - but then, the same is true of a date field needing a date picker, and a boolean field needing a checkbox. It doesn't affect the way the database needs to interact with the data it is storing. However, this might be a manifestation of the sort of problem Anssi raised - that the taxonomy I've suggested is too rich, and that we need to simplify to the practical use cases, rather than try and build a complex and descriptive API. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_o4smGG_ZNKq0s%3DDV5itL%2B1dDQCRj%2B%2Bkb1tHrgWV9sMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
