Support for composite keys

[caseybessette]

Store.get(id) and Store.remove(id) do not support composite keys. Model.save() and Model.remove() probably use the primary key, too. Perhaps it isn't worth it, but if it is, it would be good to think about it before releasing 1.0. Django has been struggling for years to add composite key support since it wasn't considered in the initial design.

[kriszyp]

Do you think that test is sufficient for now?

[caseybessette]

Thanks for that. What you have suggested would be sufficient for cases where the keys are always integers. But what about when the composite key columns are strings that may contain commas?

Perhaps the store's idProperty should optionally take a list, e.g., ['person_id', 'group_id'], and then .get() and .remove() could work like this: Store.remove({person_id: 5, group_id: 3}). Store.getIdentity(model) could return an object, {person_id: 5, group_id: 3}.

I'm not sure how composite keys best fit into a REST-style paradigm. Probably a DELETE would have to be sent to the resource's collection with a filter on the composite key columns.

[kriszyp]

Ultimately, any combination values can be unambiguously represented with a single string whether it be achieved through simple delimiter escaping, or more complex serialization. And, all the built-in stores, at least, actually require a string/scalar value, as Memory must use the id for the property names in the index, and the Rest store needs the id to construct URLs. You could create a custom store that supported composite keys with any serialization, but that I think that goes well beyond the purpose of the built-in stores.

[caseybessette]

Thank you for the explanation. That makes perfect sense.