Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
Docs Required, Release Notes Required
Description
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.
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.
Attachments
Issue Links
- causes
-
IGNITE-16023 Thin 3.0: Remove live schema leftovers from the protocol
- Resolved
- supercedes
-
IGNITE-15194 Thin 3.0: Live Schema and Schema Evolution
- Resolved
- links to