On Mon, Mar 21, 2011 at 02:20:41PM -0500, Jacob Kaplan-Moss wrote: > On Mon, Mar 21, 2011 at 2:33 AM, Christophe Pettus <x...@thebuild.com> wrote: > > I'd like to make one more pitch for a slightly different > > implementation here. My concern with CompositeField isn't based > > on the fact that it doesn't map one-to-one with a field in the > > table; it's that it doesn't have any of the semantics that are > > associated with a field. In particular, it can't be: > > > > - Assigned to. > > - Iterated over. > > - Or even have a value. > > Obviously there's no code here yet, so we don't know exactly. I'd also > be -1 on an implementation of a CompositeField that didn't have those > values. However, it's reasonably easy to come up with a CompositeField > that is assignable, iterable, and has values. Here's the basics:: > [snippet] > > Fields even sorta get saved correctly to the DB with just these few > lines of code. Of course there's a lot missing here to correctly > handle actual composite keys -- this tiny example won't work in > querysets, for example -- but the basics of the Python-side behavior's > right there.
This is exactly where I would start. One question though: should I use namedtuple in here or should we try to keep compatibility with python < 2.6? Maybe a module like django.utils.namedtuplecompat providing a fallback implementation? > > My suggestion is to create an Index type that can be included in a > > class just like a field can. > > I think we're talking slightly different concerns here: I'm mostly > interested in the Python-side API, and to my eyes a composite field > matches more closely what's happening on the Python side of things. > Python's not generating an index, after all, so using something called > "index" for compositing multiple attributes together seems weird to > me. But at the DB level, "index" makes perfect sense. Thing is, we've > always tried to make Django's APIs behave well in Python *first*, and > then think about the DB concerns. And again, to me "composite field" > matches more closely the behavior we want out of the Python side of > things. > > All that said, there's a lot to like about your Index proposal. > Perhaps there's a way we can merge these two things together somehow? The composite index could be achieved by the standard field option Field.db_index applied to a CompositeField. This would still be consistent with the rest of the API since it would not require any new construct to do this thing. To sum up, I believe the CompositeField could be a general solution to both composite primary keys and composite indexes. Michal Petrucha
signature.asc
Description: Digital signature
