snazy opened a new issue, #779: URL: https://github.com/apache/polaris/issues/779
### Describe the bug The current Polaris management spec has a few shortcomings: * It exposes and requires persistence internals (#556) like entityVersion, created/modified timestamps * It exposes the rather internal persistence model via a public API * None of the list requests/responses are use paging * It uses the generic property bags, which requires detailed knowledge of the properties on each client (#555) * Create/update/delete requests rely on persistence internals and changes are improperly validated on the server side I propose a complete overhaul of that API, as a v2 and eventually remove v1 before 1.0: * Enable pagination of list requests using opaque paging-tokens * Have a data model built on actual, distinct properties instead of generic property bags. This helps users to reason about individual properties and also helps to not accidentally exposing sensitive information. * Have specific update requests (or update request payloads) for each kind of change instead of sending the whole entity and update everything. This is much easier to reason about from the client side and also much easier to verify & validate on the server side. ### To Reproduce _No response_ ### Actual Behavior _No response_ ### Expected Behavior _No response_ ### Additional context _No response_ ### System information _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
