plusplusjiajia commented on PR #8136:
URL: https://github.com/apache/paimon/pull/8136#issuecomment-4911872410
@MgjLLL @JingsongLi flagging you both since this ties back to your
read_builder / public-API note — following up the _skip_auth thread: as the
branch stands now (flag removed), the write-corruption @MgjLLL described on Jun
24 is back. Write-path read-modify-write reads existing data through auth
(table_update L248-249
(https://github.com/apache/paimon/blob/e774825510a7610bff2a1d88488ff2c7bafd3afb/paimon-python/pypaimon/write/table_update.py#L248-L249)),
so column masking is written back over real values (L260
(https://github.com/apache/paimon/blob/e774825510a7610bff2a1d88488ff2c7bafd3afb/paimon-python/pypaimon/write/table_update.py#L260)),
independent of write permission.
The real tension seems to be _skip_auth vs. "don't touch the public
read_builder." One way to satisfy both: inject the auth provider into
new_read_builder() at construction — public signature unchanged, no flag on the
API — and route write paths through an auth-free internal builder. Writes then
sit below the auth layer
by construction, same as the Java client.
# table_scan.py
def _auth_query(self):
# Skip query-auth for internal write-path reads (read-modify-write);
otherwise
# row filtering / column masking would corrupt the data written back.
if not self._enable_auth:
return None
fn = self.table.catalog_environment.table_query_auth(
self.table.options, self.table.identifier)
...
_enable_auth is threaded from the ReadBuilder: new_read_builder() defaults
to True, write paths use an internal builder that passes False.
Is there a better way to handle this?
--
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]
