On Mon, 2014-08-04 at 13:02 -0700, Daniel Pyrathon wrote: > Hi All, > > > The current Options implementation has properties for "concrete > fields". > Technically speaking, concrete fields are data fields without a > column.
Concrete fields are data fields *with* a column, not the other way around. > The only concrete field in the codebase is ForeignObject. There are 2 > classes that inherit from ForeignObject: GenericRelation and > ForeignKey, but each of them fall into different categories (virtual > and data). The only instances of a ForeignObject in the codebase are > in the unit tests, and those occurrences can be replaced with a > ForeignKey (not tested). No, they can't be replaced with ForeignKeys. The ForeignObject tests do various things that normal ForeignKeys can't do. For one, the tests exercise multicolumn joins. But multicolumn joins aren't yet available through public APIs. Another use case not possible using ForeignKey is fetching unique reverse related object (this could be for example latest edit of an object from related list of edits). > - Do we really need concrete fields, if ForeignObject is internal and > not used in any place other than unit tests? Maybe the right approach is to make ForeignObject a relation field or a virtual field. I don't remember why ForeignObject wasn't implemented as a virtual field. > - Are there third-party packages that inherit from ForeignObject? if > yes, can anyone point which ones? Perhaps not popular, but https://github.com/akaariai/django-reverse-unique/ is something that uses ForeignObject. GitHub search gives only a lot of clones of Django's repo. There aren't likely that many users of ForeignObject yet. > > As we are formalising the Options API > (https://groups.google.com/forum/#! > topic/django-developers/XfMUjK59Sls) it would be great to reduce > complexity even more by removing the entire term "concrete fields". I'd like to keep the ability to use something like ForeignObject around. That is, there should be some way to implement the use cases mentioned above. If this requires changes to user projects that is OK for me, but if it is impossible to achieve the use cases mentioned above, then lets not remove concrete fields. In general, if at all possible we should avoid removing non-public features without offering some upgrade path to users. - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/1407238845.11410.37.camel%40TTY32. For more options, visit https://groups.google.com/d/optout.
