Support for composite keys about dstore HOT 4 CLOSED

Do you think that test is sufficient for now?

from dstore.

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.

from dstore.

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.

from dstore.

Thank you for the explanation. That makes perfect sense.

from dstore.