JingsongLi commented on PR #10462:
URL: https://github.com/apache/paimon/pull/10462#issuecomment-6080092329

   [P2] Keep the null-aware check when preserving an object's RowKind
   
   At 
[row_kind.py:80-83](https://github.com/apache/paimon/blob/fad0a7420a1bfc26528d6671d98caf447510d857/paimon-python/pypaimon/write/row_kind.py#L80-L83),
 `with_row_kind` changed from `options.get('rowkind.field') is None` to 
requiring the key to be absent. A table created with 
`Schema.from_pyarrow_schema(..., options={'rowkind.field': None, ...})` is 
accepted and retains this key, while `row_kinds` and `skip_write_row` still 
interpret its `None` value as unset. The new condition therefore omits the 
object's `_VALUE_KIND` column and the writer persists an object DELETE as 
INSERT.
   
   I reproduced this with a real filesystem catalog, primary key `id`, 
`bucket=1`, and the Python writer: commit INSERT `[1, 10]`, then DELETE `[1, 
10]`. With the parent's `with_row_kind`, the physical kinds are `[0]` then 
`[3]` and the latest read is empty. With this head they are `[0]` then `[0]`, 
and the latest read still returns `{'id': 1, 'v': 10}`. This concerns null 
options supplied at table creation; `table.copy({'rowkind.field': None})` 
removes the key and is unaffected.
   
   Please retain the previous null-aware condition, or consistently 
normalize/reject null configuration before all event-resolution paths. Add the 
accepted-null-option case to the end-to-end object-event coverage.
   
   Reviewed head: `fad0a7420a1bfc26528d6671d98caf447510d857`.
   


-- 
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]

Reply via email to