[
https://issues.apache.org/jira/browse/IGNITE-19397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-19397:
------------------------------------
Description:
IGNITE-19241 attempts to solve "client inserts data with old schema" problem by
sending the latest schema version with every tuple operation response.
However, this approach is not reliable, for example:
1. *var view = client.tables().table("FOO").recordView(); view.upsert(...)* -
now client knows schema v1
2. *client.sql().exec("ALTER TABLE FOO ADD COLUMN NEWCOL INT");* - client
alters the table, but does not know about schema v2 with new column
3. *view.upsert(Tuple.create().set("key", 1).set("NEWCOL", 100))* - v1 is used
to send data to the server, NEWCOL is ignored, data is lost. Response says that
schema v2 is available, but it is too late.
To ensure that the latest schema is used by the client and no data is lost, we
should throw an exception (with a specific error code) from
*TupleMarshallerImpl* when specified schema version is outdated: client will
receive an exception, load the latest schema, and retry the operation.
This exception should never be thrown to the user code. We can use an interface
on *org.apache.ignite.client.handler.requests.table.ClientTuple*, something
like *MatchingSchemaRequired*, and *TupleMarshallerImpl* will only perform the
check in that case.
was:
IGNITE-19241 attempts to solve "client inserts data with old schema" problem by
sending the latest schema version with every tuple operation response.
However, this approach is not reliable, for example:
1. *var view = client.tables().table("FOO").recordView(); view.upsert(...)* -
now client knows schema v1
2. *client.sql().exec("ALTER TABLE FOO ADD COLUMN NEWCOL INT");* - client
alters the table, but does not know about schema v2 with new column
3. *view.upsert(Tuple.create().set("key", 1).set("NEWCOL", 100))* - v1 is used
to send data to the server, NEWCOL is ignored, data is lost. Response says that
schema v2 is available, but it is too late.
To ensure that the latest schema is used by the client and no data is lost, we
should throw an exception (with a specific error code) from
*TupleMarshallerImpl* when specified schema version is outdated: client will
receive an exception, load the latest schema, and retry the operation.
> Thin 3.0: Return an error to client when outdated schema is used
> ----------------------------------------------------------------
>
> Key: IGNITE-19397
> URL: https://issues.apache.org/jira/browse/IGNITE-19397
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
> Affects Versions: 3.0.0-beta1
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-19241 attempts to solve "client inserts data with old schema" problem
> by sending the latest schema version with every tuple operation response.
> However, this approach is not reliable, for example:
> 1. *var view = client.tables().table("FOO").recordView(); view.upsert(...)* -
> now client knows schema v1
> 2. *client.sql().exec("ALTER TABLE FOO ADD COLUMN NEWCOL INT");* - client
> alters the table, but does not know about schema v2 with new column
> 3. *view.upsert(Tuple.create().set("key", 1).set("NEWCOL", 100))* - v1 is
> used to send data to the server, NEWCOL is ignored, data is lost. Response
> says that schema v2 is available, but it is too late.
> To ensure that the latest schema is used by the client and no data is lost,
> we should throw an exception (with a specific error code) from
> *TupleMarshallerImpl* when specified schema version is outdated: client will
> receive an exception, load the latest schema, and retry the operation.
> This exception should never be thrown to the user code. We can use an
> interface on *org.apache.ignite.client.handler.requests.table.ClientTuple*,
> something like *MatchingSchemaRequired*, and *TupleMarshallerImpl* will only
> perform the check in that case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
