Conversation
|
Important This PR touches the Lance format specification. Substantive changes to the format specification — the If this is a meaningful format change:
|
A transaction may now carry a schema metadata update alongside its operation, applied to the same manifest, and two transactions that both carry one conflict whatever their operations, so the loser is rejected before anything lands. This matches how two UpdateConfig transactions already treat schema metadata. An update on a single side is not a conflict: such an append rebases over an unrelated index build. The proto field is additive: an older reader applies such a transaction's data without its metadata. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fd2f590 to
aa34612
Compare
There was a problem hiding this comment.
🟡 Gate recommendation: maintainer decision required.
This adds a schema-specific composition mechanism to the stable V1 transaction envelope while Transaction V2 is actively defining general ordered actions, including UpdateSchemaMetadata. A closely analogous top-level metadata proposal (#6255) was previously held for this choice because both wire contracts would need long-term support.
The maintainers need to choose between:
- shipping the narrow V1 extension now, which delivers atomic data + schema metadata sooner but makes older writers ignore the modifier during conflict analysis and commits the project to a second composition model;
- expressing this as Transaction V2 actions, which is broader and fail-closed for older writers but delays this use case until that implementation is ready.
Please choose based on whether the immediate schema-metadata use case justifies a permanent V1 contract, and record that decision through the required format vote.
|
Closing this — looking into another approach. |
A transaction may now carry a schema metadata update alongside its operation, applied to the same manifest, and two transactions that both carry one conflict whatever their operations, so the loser is rejected before anything lands. This matches how two UpdateConfig transactions already treat schema metadata. An update on a single side is not a conflict: such an append rebases over an unrelated index build. The proto field is additive: an older reader applies such a transaction's data without its metadata.