> So - it's one of those things that *should* be documented and
> fomalized; it's just waiting on someone with the spare time to do the
> job.
Sounds good ! Any estimation on how big is the cleaning task ? I know
documentation task can go forever :)
And what about the extra features I suggested ? A more user-friendly
way to get all -data- fields (including m2m, excluding pointers), an
easy way to get the name of the pk field of the first parent.
This would allow the user to forget that there is some multi-table
inheritance under the hood. Most of the time - when using the models -
you just use them transparently, e.g.
class Animal(models.Model):
code = models.IntegerField(primary_key=True)
name = models.CharField(max_length=100)
class Mouse(Animal):
lab = models.CharField(max_length=100)
It is great that you can do :
>>> my_mouse.lab, my_mouse.name
('acme', 'pinky')
instead of :
>>> my_mouse.lab, my_mouse.animal_ptr.name
('acme', 'pinky')
so MTI is transparent, if you know what I mean. Thing is, there is no
equivalent when you introspect your model ... which gives extra-work
to the developer, and makes introspecting more complicated. Instead of
having :
>>> [f.name for f in Mouse._meta.fields]
['code', 'name', 'animal_ptr', 'lab']
I'd love to have something in the following (not to mention the m2m
fields)
>>> [f.name for f in Mouse._meta.get_fields(exclude_ptrs=True)] #
Or why not get_all_field_names(exclude_ptrs=False)
['code', 'name', 'lab']
Because that's all you need to know in most of the cases.
Same pb with the primary key. The only way I found to get the name of
the pk field is to do :
>>> Animal._meta.pk.name
'code'
Which with Mouse will become :
>>> Mouse._meta.pk.name
'animal_ptr'
Once again, if you want to know the name of the pk field, you would
expect (MTI being transparent from the user perspective), to get
'code' instead.
Or did I miss some methods/properties from the _meta API ?
Cheers,
Sébastien
On Sep 23, 12:10 pm, Russell Keith-Magee <[email protected]>
wrote:
> On Fri, Sep 23, 2011 at 4:46 PM, sebastien piquemal <[email protected]> wrote:
> > Hi all !
>
> > So this might be a stupid idea, or it might have been answered
> > before ... actually it seems so obvious to me that you have probably
> > thought of it before and rejected it !!! But let's try ...
>
> > I was wondering, why isn't there a user API for introspecting models ?
>
> > OK, there is an API, through '_meta', which is not documented (unless
> > you read the source), which is not addressed to users, and is
> > therefore likely to change, and therefore unreliable.
>
> Seehttps://code.djangoproject.com/ticket/12663
>
> _meta is in a weird limbo state. It isn't *technically* stable API,
> and it isn't documented, but it's *effectively* a stable API -- both
> because it hasn't changed in a long time, and there is lots of code in
> the wild that would break hard if we changed it.
>
> So - it's one of those things that *should* be documented and
> fomalized; it's just waiting on someone with the spare time to do the
> job.
>
> There's also a light cleanup required. There are some parts of the
> _meta api -- like get_field() -- that are completely uncontroversial,
> and would clearly be stabilized as is. However, there are also API
> entry points that are more esoteric, and in some cases, are represent
> potentially duplicated functionality in the _meta structure. What is
> needed is for a motivated someone to do an audit, cleanup, and
> documentation of the code that is there.
>
> Yours,
> Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
