Hi Michal, I'm looking forward to seeing this project take shape! Comments below:
On 05/12/2011 06:41 AM, Michal Petrucha wrote: [..] > The constructor of a CompositeField will require at least two > positional parameters, each positional parameter will be a single > atomic field. The order of this parameters will be important as > explained below. The parameters will have to be field instances, lazy > loading won't be necessary (the recommended place of composite field > definitions will be after atomic fields). This sounds fine. > CompositeField will accept these three field options: > - db_index (creates a multi-column index across the underlying fields) > - primary_key (creates a composite primary key in the model) > - unique (creates a unique constraint for the set of fields) > > Other field options either wouldn't make sense or would be too > difficult to implement. > > There is a clash with the current API here, in the ``unique`` option. > This would supersede the current ``unique_together`` Meta option. I > see three options possible: > > 1) Leave out the ``unique`` option and live with ``unique_together``. > This would pribably imply also leaving out ``db_index``, otherwise > the API would be a complete mess. > > 2) Allow ``CompositeField.unique`` but also keep ``unique_together``. > The problem I see with this approach is that there would be two > quite different ways to achieve the same effect. > > 3) Make ``CompositeField.unique`` the way to go and deprecate > ``unique_together``. > This way, specifying a unique constraint on a tuple of fields would > work the same way it works on single fields which is IMO a > significant benefit. There's, however, the issue of breaking > backwards compatibility. Furthermore, one would have to add a new > field, albeit virtual, just to create a simple constraint, which > may seem weird to some. I agree with Javier - I favor option 2. In my mind, although the final result at the database level may be the same (a unique index across multiple database columns), in conceptual terms at the ORM level it is really two different things. There are many cases where I want to specify that two fields should be unique together, but they really are two separate fields; I'm never going to want to access it as a single field or composite value. In this case, specifying a CompositeField would confuse the intent and be more verbose than unique_together. I think the conceptual distinction is clear, and it will actually be less confusing to users to have both options available than to have CompositeField become the only way to specify an index on multiple columns. > One minor detail, should the field silently ignore invalid options or > should it issue warnings? Explicit is better than implicit, and errors should never pass silently unless explicitly silenced. If the option is invalid, it should not just be a warning, it should be an outright failure (though if the check is expensive, it could possibly happen in model-validation rather than always at runtime). > The value of a CompositeField will be represented by an instance of a > CompositeValue class. This will be a descendant of tuple and will > resemble namedtuple present in Python >= 2.5. It will support > iteration, numbered indexing and access to individual field values > using attributes corresponding to underlying field names. The order of > values will be the same as the order of fields specified in the model > definition. Yes, Tom is right of course - now that Python 2.5 is minimal version, we can just use namedtuple. > Assigning a value to a CompositeField will be possible using any > iterable as long as its length equals the number of atomic fields (and > the values can be assigned to the corresponding fields, obviously). I mentioned this in an earlier thread, but I'd really like to see the API allow me to specify my own class as the value class, as long as it satisfies some basic API requirements. In my mind the long-term goal here is that GFKs should be reasonably implementable as a CompositeField or a CompositeField subclass without exploiting undocumented internal APIs. If there are implementation complexities that push this feature out of scope for GSoC, that's fine - but I want to make sure we don't make that future expansion difficult by design choices we make now. [...] > I'm also thinking about implementing an abstract class, VirtualField. > This could be useful mainly as a base class for fields with no direct > database column. That means, it would mainly handle things like > add_to_class (adding itself to the list of virtual fields instead of > local ones), specifying arbitrary lookup filters when asked for one > etc. CompositeField could then be a descendant of this class. > > However, I can't currently imagine any other use-case for this > abstract class than CompositeField. The question is, then, is there > any interest in having an abstract mechanism like this? Can anyone > imagine a use-case? (The question is, should I implement this > functionality directly inside CompositeField or factor it out into > something more general?) I wouldn't spend time on something we don't have any use case in mind for (unless making this split makes the code easier to read and understand). This is something that most likely could easily be done later, if we find we need it. Carl -- 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.
