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/a6fcfc1e-e76f-42da-ad4f-c2eca9a8a6ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
