On Saturday, August 16, 2014 4:38:30 AM UTC+3, Russell Keith-Magee wrote: > > b) "Relating" data fields - This means ForeignKey. Fields that manifest as > a single column, but represent a relation to another model. >
This definition will not work when multicolumn foreign keys are introduced. Especially not with the name foreign_key_fields. This would either mean that relating data fields do contain fields that have more than single backing column, or that foreign_key_fields do not contain all foreign key fields. Michal Petrucha's work on virtual fields aims to make ForeignKeys virtual fields - they have one or more backing pure data fields, and then the relation is handled by a virtual fields. The work done by him shows that this way works well. The patch was actually close to committable already during 1.7 development, but as it didn't play well with migrations we had to defer it. The point here is that I expect that we will want to make ForeignKeys virtual fields soonish. This doesn't play well with the categorization. > d) "Relating" external fields - This means ManyToMany fields. Fields that > are manifested as an external table, but represent a relation to a > different model. > Should we define this category as m2m fields? Calling it many_to_many_fields, but defining it as including all external storage fields seems a bit problematic. > So - firstly, we need a sanity check. Does this taxonomy capture all field > types that you can think of? Are there any interpretations of composite > fields, or any other esoteric field type (existing or imagined) that don't > fit in this taxonomy? > It seems the proposed API has fields in one, and only one category. Maybe it would be better to have categorization where fields fall in to multiple categories? The categories could be data, virtual, relation, reverse_relation and m2m. For example m2m field would be virtual, related or reverse_related and of course m2m. In the future a foreign key would create a backing data field. The foreign key itself would be virtual relation field. The reverse side of the foreign key would be virtual and reverse_related. GenericForeignKey would also be a virtual related field (with two backing data fields). I don't see how a TranslationField would fit into the above categorization. A TranslationField is defined as a field that gets a single translation from related translations table. So, it is the reverse side of a foreign key with an additional restriction on language (in effect generating a join condition JOIN article_translations ON article.id = article_translations.article_id AND article_translations.language = 'fi'). At least as defined this isn't in category g as it doesn't return all reverse objects of category b. It doesn't fit in to any other category either. So, we need some changes to the wording. As another example we might someday want to allow fully custom join condition fields. These fields wouldn't be foreign key, external data nor many to many fields nor the reverse of those categories Comments welcome. Obviously, this has enormous potential to devolve into > bike shedding, so I'd appreciate it if people kept that in mind. If you > have a preference for something like short vs long form names, feel free to > state it, but please don't let this devolve into arguments over the > relative merits of pith over verbosity in API naming. It's much more > important that we clarify the matters of substance - i.e., that we have a > complete and correct taxonomy - not that we fixate on the names themselves. > I don't think users actually want to get fields based on the suggested categorization. I feel we get an easier to use and more flexible API if we have higher level categories and allow fields to match multiple categories. As a practical example if I want all relation fields, that is going to be hard using the suggested API. Getting all relation fields is a more realistic use case than getting related virtual objects. If we want to have all fields to match single and only single category, then we need to redefine the categories to make sure ForeignKeys as virtual fields are possible, and that more esoteric custom join based fields fit in to the categorization. BTW where are the github discussions located? I didn't spot them from the referenced PR 2894. - 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 [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/ac9b65ae-9902-4c05-a51e-b1dbcf17bd96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
