[
https://issues.apache.org/jira/browse/IGNITE-20106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-20106:
---------------------------------------
Description:
As per
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Overallflow
, the schema version that the client sends with each request should be
validated against the server-side schema version corresponding to the given
table in the tx. If it does not match, SCHEMA_VERSION_MISMATCH_ERR should be
sent to the client along with the correct server-side schema version.
The check should be done on a tx coordinator. Also, the coordinator must check
that all the tuples sent by the client (in the same request) are encoded using
the same schema version.
The IEP defines baseTs as tableEnlistTs(tx, table). On the first iteration, we
should implement a simpler way to calculate baseTs (max(beginTs,
tableCreationTs) to allow created tables to 'appear' in a transaction or even
simply beginTs). The full-blown baseTs calculation will be implemented in
IGNITE-20108. It makes sense to do it later because it requires substantially
more work to only support a not-to-common use-case (ALTER TABLEs after a
transaction started, but before it enlisted the table).
was:
As per
https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Overallflow
, the schema version that the client sends with each request should be
validated against the server-side schema version corresponding to the given
table in the tx. If it does not match, SCHEMA_VERSION_MISMATCH_ERR should be
sent to the client along with the correct server-side schema version.
The check should be done on a tx coordinator. Also, the coordinator must check
that all the tuples sent by the client (in the same request) are encoded using
the same schema version.
The IEP defines baseTs as tableEnlistTs(tx, table). On the first iteration, we
should implement a simpler way to calculate baseTs (max(beginTs,
tableCreationTs) to allow created tables to 'appear' in a transaction or even
simply beginTs).
> Check that client schema version matches server-side schema version
> -------------------------------------------------------------------
>
> Key: IGNITE-20106
> URL: https://issues.apache.org/jira/browse/IGNITE-20106
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: iep-110, ignite-3
> Fix For: 3.0.0-beta2
>
>
> As per
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-110%3A+Schema+synchronization%3A+basic+schema+changes#IEP110:Schemasynchronization:basicschemachanges-Overallflow
> , the schema version that the client sends with each request should be
> validated against the server-side schema version corresponding to the given
> table in the tx. If it does not match, SCHEMA_VERSION_MISMATCH_ERR should be
> sent to the client along with the correct server-side schema version.
> The check should be done on a tx coordinator. Also, the coordinator must
> check that all the tuples sent by the client (in the same request) are
> encoded using the same schema version.
> The IEP defines baseTs as tableEnlistTs(tx, table). On the first iteration,
> we should implement a simpler way to calculate baseTs (max(beginTs,
> tableCreationTs) to allow created tables to 'appear' in a transaction or even
> simply beginTs). The full-blown baseTs calculation will be implemented in
> IGNITE-20108. It makes sense to do it later because it requires substantially
> more work to only support a not-to-common use-case (ALTER TABLEs after a
> transaction started, but before it enlisted the table).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
