-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for composite keys #31
Comments
Do you think that test is sufficient for now? |
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 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. |
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. |
Thank you for the explanation. That makes perfect sense. |
Store.get(id)
andStore.remove(id)
do not support composite keys.Model.save()
andModel.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.The text was updated successfully, but these errors were encountered: