> > 1. Secondary indexes make lookups by-id and by-name "atomic" in the face of > concurrent updates. Some databases that support transactions but not > secondary indexes will use transactions over "index tables"
I propose to delegate this to the Persistence implementation and not expose anything about "indexes" in the interfaces used by Polaris services. I believe it is best to formulate the interface in terms of what queries need to be supported and let the implementation find the most appropriate way to do that in each particular case. 2. The base building block for all concurrent-update resolution is "compare-and-swap" on the entityVersion I think we need to be more specific about that if we make it part of the Persistence contract. What is the object of the CAS operation in case of a multi-table change (e.g. when coming from the REST Catalog API)? I do not think we have to expose CAS as a feature of the Persistence API. I tend to think it might be preferable to formulate the API in terms of batched changes related to a particular prior state and let Persistence implementations use CAS or SERIALIZABLE Tx where appropriate and based on supported database features. WDYT? Thanks, Dmitri.
