On Fri, Sep 23, 2011 at 6:10 PM, sebastien piquemal <seb...@gmail.com> wrote: >> 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 :)
About as long as this piece of string that I'm holding. Oh, wait - you can't see the string? Let me hold it up for you... :-) Seriously -- I can't really answer this. It's not a completely trivial task, but it's not complex on the order of "multi-db" or "no-sql support" either. The first step really is an audit -- a rough cut at documenting everything that is there at the moment. Once we have that, we can look at how the existing API is being used, and evaluate the cleanup opportunities. Once that's done, we'll be in a much better position to evaluation how much work is involved. > 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. ... > Or did I miss some methods/properties from the _meta API ? Off the top of my head, I can't answer this. It's *possible* that there might be some way to do this, but I'd need to go digging to work out for sure, and I can't refer to the documentation to find out easily :-) However, I wouldn't be at all surprised if it isn't possible. The _meta API is mostly designed for Django's own internal needs, and Django needs to make a very clear distinction between fields and m2m's, forward and reverse fields, and so on; hence the distinctions that exist in the current API. "Iterating over all fields" doesn't make much sense from an internal perspective, because different types of fields need to be handled differently. Similarly, the "hidden" _ptr fields might not be important from a public visibility perspective, but they're very important from an internal perspective. That said, just because Django doesn't have a use for the API doesn't mean it wouldn't be useful. If you can propose a clean way to augment the _meta API to provide this sort of capability, I don't see any fundamental reason why it shoudn't be included. 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 django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
