[
https://issues.apache.org/jira/browse/IGNITE-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15901:
--------------------------------------
Description:
h3. Motivation.
The Live-schema concept looks like a very disputable thing. It may cause
unwanted schema change if a new/outdated/broken client puts the data to the
grid. Implicit schema changes may lead to unpredicted behaviour from the user
perspective.
In most cases, user application and schema are mutually dependent things. Thus,
the application model and schema must be changed consistently.
In the general case, it is impossible to keep the consistency and the decision
on that must be taken on the user side.
Actually, there are 2 different use cases for the schema-last approach:
* The first one, when a user creates a table without specifying a schema and
Ignite automatically create the initial schema version on the first 'put'
operation. This may be useful for PoC or tests.
* The second one, when a user changes data model classes, and Ignite update the
schema implicitly on the next 'put' operation to make schema match the new data
model. Here are many limitations we can do transparently without any additional
configuration from the user side.
Thus, the first case may be a not too bad idea. However, the second case looks
error-prone.
h3. Suggestion.
Drop LiveSchema mode and remove all the related code.
Postpone all the related tasks unless we will have clear explanation on how it
should work and how a user should use it.
was:
h3. Motivation.
The Live-schema concept looks like a very disputable thing. It may cause
unwanted schema change if a new/outdated/broken client puts the data to the
grid. Implicit schema changes may lead to unpredicted behaviour from the user
perspective.
In most cases, user application and schema are mutually dependent things. Thus,
the application model and schema must be changed consistently.
In the general case, it is impossible to keep the consistency and the decision
on that must be taken on the user side.
Actually, there are 2 different use cases for the schema-last approach:
* The first one, when a user creates a table without specifying a schema and
Ignite automatically create the initial schema version on the first 'put'
operation. This may be useful for PoC or tests.
* The second one, when a user changes data model classes, and Ignite update the
schema implicitly on the next 'put' operation to make schema match the new data
model. Here are many limitations we can do transparently without any additional
configuration from the user side.
Thus, the first case may be a not too bad idea. However, the second case looks
error-prone.
h3. Suggestion.
Drop LiveSchema mode and remove all the code related to this unless we will
clear explanation on how it should work and how a user should use it.
> Drop Live schema support.
> -------------------------
>
> Key: IGNITE-15901
> URL: https://issues.apache.org/jira/browse/IGNITE-15901
> Project: Ignite
> Issue Type: Bug
> Reporter: Andrey Mashenkov
> Priority: Major
> Labels: iep-54, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation.
> The Live-schema concept looks like a very disputable thing. It may cause
> unwanted schema change if a new/outdated/broken client puts the data to the
> grid. Implicit schema changes may lead to unpredicted behaviour from the user
> perspective.
> In most cases, user application and schema are mutually dependent things.
> Thus, the application model and schema must be changed consistently.
> In the general case, it is impossible to keep the consistency and the
> decision on that must be taken on the user side.
> Actually, there are 2 different use cases for the schema-last approach:
> * The first one, when a user creates a table without specifying a schema and
> Ignite automatically create the initial schema version on the first 'put'
> operation. This may be useful for PoC or tests.
> * The second one, when a user changes data model classes, and Ignite update
> the schema implicitly on the next 'put' operation to make schema match the
> new data model. Here are many limitations we can do transparently without any
> additional configuration from the user side.
> Thus, the first case may be a not too bad idea. However, the second case
> looks error-prone.
> h3. Suggestion.
> Drop LiveSchema mode and remove all the related code.
> Postpone all the related tasks unless we will have clear explanation on how
> it should work and how a user should use it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
