On Thu, 2014-08-21 at 11:07 +0800, Russell Keith-Magee wrote:
> Sure - and the purpose of this thread is to tease out what those > "useful" flags are. At the moment, it's not clear to me where exactly > the conceptual holes lie from your perspective. As I said, the API > I've proposed here is sufficient to meet all *current* use cases in > the code base. > > As best as I can make out, it appears you see a problem with the > concept of "hidden" - because in various circumstances, different > fields will be "hidden" in different ways (especially in the > composite/virtual foreign key future). Taking that "future virtualised > foreign key" case - if you're dealing with the database, it's the > virtual field that needs to be hidden, because the database only cares > about fields with an actual column/table underneath it; but if you're > dealing with a form, you don't want the field for the underlying > field, you want the virtual field. However, given a virtual field > representation, I imagine it is possible to get back to the field (or > fields) that hold the underlying representation; all that is important > is that you can iterate over a list of "fields", and from there, > determine a list of column names. The fact that the column name comes > from a different underlying column isn't important; what's important > is that the "foreign key" is only counted once in the introspection > process. > > > So - what I really need here is a counterproposal from someone > familiar with the composite key work. I'm not bound to any of the > details of the proposal I've given here - I'm just relating the end > point of work from SoC. It works with the current use cases exposed by > Django, but when this hits master, we're going to need to live with it > long term, so I want to make sure we're not boxing ourselves into a > corner, or introducing categorisations that aren't representative. No counterproposal from me - as I said earlier I think the get_fields() API as defined is sufficient. We already have one field that doesn't play well with the categorization when it comes to model serialization or initialization. That field is GenericForeignKey. If it is returned by get_fields(data=True), then get_fields(data=True) can't be used for model serialization or initialization without filtering the return set further down using flags. In short, I see all concrete fields as an important category itself. We can't provide that with the proposed categorization. The easiest way to get all the concrete fields would be [f for f in get_fields(**return_all_fields) if f.concrete]. It is also notable that ordering matters, and for that reason inspecting the underlying fields of a virtual field doesn't sound promising. For the ForeignKey backwards compatibility problem - maybe we could get the virtual fields patch committed for 1.8. This way we wouldn't have any backwards compatibility problem to begin with. The composite fields patch was otherwise close to committable, but the problem was that it didn't play well with migrations. I have no idea what the actual problems were. Anybody have more knowledge why composite fields do not play well with migrations, and what is needed to solve the problems? - Anssi -- 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/1408604445.11410.321.camel%40TTY32. For more options, visit https://groups.google.com/d/optout.
