dennishuo commented on issue #766:
URL: https://github.com/apache/polaris/issues/766#issuecomment-2610652389
The current code structure probably exaggerates the expected transaction
semantics needlessly, and a few minor adjustments should be able to
significantly lighten the requirements. In particular:
1. Most of the independent one-shot reads happen to be structured as
`runInReadTransaction` but aren't actually depending on transaction semantics
2. The `writeToEntities`, `writeToEntitiesChangeTracking`,
`writeToEntitiesActive` triplet is actually more for serving the role of
secondary indexes than truly being separate tables. There are caveats depending
on how we approach vestigial plans for UNDROP functionality, but it's worth
discussing whether these make sense to push down to the `MetaStoreSession`
layer and even refactoring the EclipseLink one to better portray these as
serving efficient queries on a single table
3. A few operations actually do uniquely require various flavors of
transactions across multiple rows or tables; we should enumerate these
separately from the majority of "core" actions. Of particular interest off the
top of my head:
a. CreateCatalog relationship to a "storage integration" object and
bootstrapped CatalogRoles
b. CreatePrincipal with "principal secrets"
c. Iceberg-level multi-table commit that uses
updateEntitiesPropertiesIfNotChanged
d. DropTable atomically adding a TaskEntity for cleanup (other
DropEntity types as well technically, but the main non-trivial case is for file
cleanup when PURGE=true)
--
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]
