Hi All, First of all, thanks Russell for bringing this discussion up.
*Regarding get_fields complication* Throughout the development of this project, I have realised that 90% of the API usage inside and outside of Django can rely entirely on 4 or 5 cached properties. The most used API calls are: - get all data fields - get all m2m fields - get all related data - get all related m2m - get field by name These 5 are by far the most used endpoints of the API. Said this, there is a small set of very necessary endpoints that are called in only a few places, such as: - get all related data with hidden fields - get all related data including proxy relations - get all data fields that have a column Some of these, have been refactored in-place and are not part of the API any more. Others unfortunately are still subsets of the API but I personally see very few people (none actually) wanting this information for other use. For this reason, as an end-user, you should think of this API only as a set of (cached) properties as most likely you will never need to use the get_fields API directly. To make this a little clearer, I have attached an image of the API. <https://lh4.googleusercontent.com/-GgtrNCW5-4Y/U_HC79vrEbI/AAAAAAAALlI/Ef6EiM2DR3M/s1600/meta%2B-%2BNew%2BPage.jpeg> *Regarding FileField* I think this is still a data field. The fact that it stores an image path and it's getter/setter does some magic does not change it's "identity". ImageField is, based on the definition of virtual so far, a virtual field. On Monday, August 18, 2014 6:50:04 AM UTC+2, Russell Keith-Magee wrote: > > Hi Shai, > > On Sun, Aug 17, 2014 at 3:44 AM, Shai Berger <[email protected] > <javascript:>> 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/16a14d37-383f-4e61-b026-20e16f38d4b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
