I was also thinking of MetaModels or something instead of Options, as I think it makes it more obvious what it's for.
On Friday, 1 August 2014 00:49:41 UTC+2, Josh Smeaton wrote: > > I was thinking "column" fields would make sense but it clashes with the > internal concept of columns (Col types), and is only name-appropriate for a > database backend. I'm not sure these are actually problems worth > considering though. > > On Friday, 1 August 2014 01:07:21 UTC+10, Collin Anderson wrote: >> >> This is awesome. I've always wished that django.contrib.admin used only >> documented django APIs. It's unfair to 3rd party apps. :) I'm also thankful >> I won't need to import bitflags just to use this API. >> >> >>> The Options API is at the core of Django, it enables introspection of >>> Django Models with the rest of the system. This enables lookups, queries, >>> forms, admin to understand the capabilities of every model. The Options API >>> is hidden under the _meta attribute of each model class. Options has always >>> been a private API, but Django developers have always been using it in >>> their own projects, in a non-official way. As part of my SoC project, I am >>> exposing the new API for public use. As we are also formalizing a new >>> API that has always existed, It is important to revisit the terminology and >>> document it. >> >> >> The word "Options" doesn't make much sense to me. I realize that both >> "meta options" and the fields are stored on the same object. I think "Model >> Meta API" or "Model Schema API" or "Model Fields API" or "Model Class API" >> or "Model Definition API" or "Model Structure API" would make more sense. >> >> In the current docs, we're saying that meta options are "anything that's >> not a field", and it may make sense to keep "options" to referring to that. >> https://docs.djangoproject.com/en/dev/topics/db/models/#meta-options >> >> I prefer "concrete" to "data" as it makes the parallel with "virtual" >>> more obvious. >> >> >> Does this include m2m? We could call 'em "column" fields, as in fields >> that actually map to a column on the database table. >> >>> >>> - "related_objects" > "reverse_rel" >>> - "related_m2m" > "reverse_m2m" >>> - What about reverse o2o, do they currently fall under >>> "related_objects"? >>> - The main issue I have with "related" is that it doesn't provide a >>> sense of direction, after all both sides of a FK have related objects >>> waiting on the other end. I also like the symmetry between "m2m" and >>> "reverse_m2m". >>> - Django isn't always consistent (and sometime actually wrong) in >>> naming relations, especially indjango/db/models/fields/related.py. >>> Now that we start documenting all those things, I see value in getting >>> it >>> right. >>> >>> Maybe also "hidden" -> "reverse_hidden" to be consistent? >> >> Maybe export_map -> return_names. or return_names_map. >> > -- 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/38ebc85e-7b64-4ec9-bccf-2e686d58ae3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
