Details
-
Epic
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
Catalog Service
Description
Right now database schema information in Ignite 3.0 is stored and treated as regular configuration. All business processes related to schema changes are distributed via internal mechanisms of configuration engine and orchestrated ad-hoc by consumer components like TableManager or IndexManager.
But there is a strong evidence that API and guarantees of configuration engine don't satisfy important requirements that emerge in the field of db schema management.
So we need to stop treating schema as any other configuration and move it to a separate component called Catalog Service.
This component will provide high-level API to modify the schema and will take responsibility for all other necessary processes like synchronizing schema changes between nodes, managing schema change events, notifying all necessary components and providing orchestration between them.
Attachments
Issue Links
- causes
-
IGNITE-20617 Sql. Performance degradation in SELECTS (2 nodes VS 1 node)
- Resolved
- fixes
-
IGNITE-19223 Implement accumulation of schema updates in CatalogService
- Resolved
-
IGNITE-19224 Implement reading a table schema by a timestamp
- Resolved
- is duplicated by
-
IGNITE-19768 Port configured tables workaround from configuration to Catalog
- Resolved
-
IGNITE-19752 Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog
- Closed
- is related to
-
IGNITE-19792 Support @Immutable logic for distributed configuration
- Open
- mentioned in
-
Page Loading...