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/f2e17f7b-8901-46fc-8e78-d560f4e4e40b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
