> Can we create a validator to prevent this from happening? We don't have this problem with the Java implementation. `BaseDVFileWriter` merges the previous DV with the new delta DV. So there is no `undelete` behavior. I am not aware of any Java API to allow "undelete". So we probably don't need to add any validation code in the Java impl.
Just thought it is good to spell it out in the spec so that clients/engines can be clear about the expected behavior. On Fri, Nov 21, 2025 at 12:18 PM Péter Váry <[email protected]> wrote: > Are we specifically stating somewhere that all row-ids should be higher > than or equal to the snapshot's `first-row-id`? > In my mental model the `first-row-id` is only applicable for rows that > don't have a specific row-id assigned. > > Noneless, I agree that the `row-id` and the `last-updated-seq-num` should > have changed to a new one, so we can say that undeleting a row is not > allowed because of this. > > Can we create a validator to prevent this from happening? > > > > Steven Wu <[email protected]> ezt írta (időpont: 2025. nov. 21., P, > 21:11): > >> The undeleted row would have invalid `row-id` and `last-updated-seq-num`. >> Since it is a new row (added back), it should have the `row-id` higher than >> or equal to the snapshot's `first-row-id` and the `last-updated-seq-number` >> should inherit/have the new snapshot's sequence number. >> >> On Fri, Nov 21, 2025 at 11:48 AM Steven Wu <[email protected]> wrote: >> >>> Hi, >>> >>> Should we clarify the V3 spec to explicitly formid "*undelete*" of a >>> row by unsetting the DV bit? Unsetting a DV bit essentially adds a row with >>> lower row-id than the snapshot's first-row-id, which would violate the row >>> lineage spec. With the restriction, DV cardinality should be monotonically >>> increasing. >>> >>> Thanks, >>> Steven >>> >>
