Summarizing the conversation I just had with Daniel in IRC:

What if we thought about just documenting the high-level api, like what
ModelForms uses, and not necessarily document what the django low levels:
ORM, migrations, etc would need to use.
Could we get away with not documenting _meta.get_fields(**kwargs) and just
document these cached attributes:
_meta.data_fields (currently _meta.concrete_fields)
_meta.m2m_fields (currently _meta.many_to_many)
_meta.virtual_fields
_meta.related_objects
_meta.related_m2m
_meta.get_field('field_name') (no kwargs)
_meta.field_names
The question then is: is this a good API.
You can chain those together or filter them all you want by hand, and deal
with caching yourself.
In the high level API, you shouldn't care how a particular field is stored
in the database. If the high level API really wants do distinguish between
local_fields and parent_fields (even though it shouldn't care), it can
check something like field.model = TheModel.

My thoughts on the proposal:

It seems to me m2m _is_ a virtual field, and in the high-level API, I think
we should try to avoid whether or not a particular field is virtual or not.
What's virtual for one database could be native in a different database.
I don't have a clear picture in my head of how to split up the fields, and
I wonder if just exposing a _meta.fields (which includes data + m2m +
virtual) and instead having attrs on fields to describe themselves, like
field.rel, field.db_column, field.cant_be_used_until_after_model_has_an_id,
field.rel.is_m2m, etc.

-- 
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/CAFO84S7sYCkh%2BS8ycJXGTjcrHLwPvX3-dQOC9Cp%3DebeT4yO8xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to