> > 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. > > 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 point I forgot to mention in the original e-mail is that there would be an inconsistency: creating a unique index will be possible using either a unique CompositeField or unique_together where as a non-unique index will be possible only with an explicit CompositeField. At least as far as I know there is currently no option to create a non-unique index over several 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). Thanks for the pointer, model validation looks like the right place for this. > 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'll make it possible to insert custom hooks into the assignment/retrieval routines which should be sufficient for the purposes of GFKs. > [...] > > 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. Fair enough, unless it turns out to be a better approach anyway. (-: Michal
signature.asc
Description: Digital signature
