Hi Daniel,
I'm a little confused because if I understand correctly you introduced the
concept of "data" field that you describe as "any field that has an entry on
the database", but how is that different from the earlier concept of "concrete"
fields.
For now FO, FK and O2O all fall under the "concrete" fields category but my
take is that eventually all relations should be "virtual", some of them relying
on one or more concrete fields (i.e. composite). Currently virtual fields are
not part of the public API, and IIRC they are not allowed to have form fields.
Eventually we'll need the concept of "data" fields that span a subset of both
concrete and virtual fields of a given model for the purpose of acquiring and
presenting data (i.e. forms or admin). For instance:
class Model:
name = model.CharField() # concrete & data
fk_col1 = models.IntegerField() # concrete only
fk_col2 = models.IntegerField() # concrete only
fk = models.ForeignKey(col1, col2) # virtual & data
--
Loic
On Aug 4, 2014, at 10:02 PM, Daniel Pyrathon <[email protected]> wrote:
> Hi All,
>
> The current Options implementation has properties for "concrete fields".
> Technically speaking, concrete fields are data fields without a column. 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).
> So, my question is:
>
> - Do we really need concrete fields, if ForeignObject is internal and not
> used in any place other than unit tests?
> - Are there third-party packages that inherit from ForeignObject? if yes, can
> anyone point which ones?
>
> Perhaps akaariai and loic84 can help, as I know they have done work in this
> area.
>
> 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".
>
> Thanks,
> Daniel Pyrathon
--
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/9CD758ED-968C-4B92-9EE0-67AE12DFDB4E%40sixmedia.com.
For more options, visit https://groups.google.com/d/optout.
