[
https://issues.apache.org/jira/browse/IGNITE-26501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-26501:
--------------------------------------
Description:
CatalogTableDescriptor.tableVersion() was renamed to latestSchemaVersion to
better reflect the pusposes, because it was just a shortcut from getting the
latest schemaVersion. This was introduced in this commit:
[https://github.com/apache/ignite-3/commit/09116a30f7b5c92e50375d5b588821d4ec1b705a]
This seems wrong as schema version is used for caching purposes of
CatalogTableDescriptor which has other fields not related to the schema that
can be changed independently.
Historically tableVersion was a separate conception and field but later was
merged for some reason. This also created a workaround of bumping a schema
version every time when table descriptor was changed is necessary.
The proposal is to split those concepts making them independent as they should
be. The schema version should be bumped only when table columns are changed.
The table version should be changed when table descriptor was changed.
Actually, we can use CatalogTableDescriptor.updateTimestamp as a "table
version" instead of getting a tableVersion field back. UpdateTimestamp is
strictly monotonic as schemaVersion, but we don't require continuity.
was:
CatalogTableDescriptor.tableVersion() was renamed to latestSchemaVersion to
better reflect the pusposes, because it was just a shortcut from getting the
latest schemaVersion. This was introduced in this commit:
[https://github.com/apache/ignite-3/commit/09116a30f7b5c92e50375d5b588821d4ec1b705a]
This seems wrong as schema version is used for caching purposes of
CatalogTableDescriptor which has other fields not related to the schema that
can be changed independently.
Historically tableVersion was a separate conception and field but later was
merged for some reason. This also created a workaround of bumping a schema
version every time when table descriptor was changed is necessary.
The proposal is to split those concepts making them independent as they should
be. The schema version should be bumped only when table columns are changed.
The table version should be changed when table descriptor was changed.
Actually, we can use CatalogTableDescriptor.updateTimestamp as a "table
version" instead of getting a tableVersion field back. UpdateTimestamp is
strictly monotonic as schemaVersion, but we don't expect continuity.
> Sql. Use CatalogTableDescriptor version instead of schemaVersion for caching
> purposes
> -------------------------------------------------------------------------------------
>
> Key: IGNITE-26501
> URL: https://issues.apache.org/jira/browse/IGNITE-26501
> Project: Ignite
> Issue Type: Improvement
> Components: catalog ai3
> Reporter: Viacheslav Blinov
> Assignee: Andrey Mashenkov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CatalogTableDescriptor.tableVersion() was renamed to latestSchemaVersion to
> better reflect the pusposes, because it was just a shortcut from getting the
> latest schemaVersion. This was introduced in this commit:
> [https://github.com/apache/ignite-3/commit/09116a30f7b5c92e50375d5b588821d4ec1b705a]
> This seems wrong as schema version is used for caching purposes of
> CatalogTableDescriptor which has other fields not related to the schema that
> can be changed independently.
> Historically tableVersion was a separate conception and field but later was
> merged for some reason. This also created a workaround of bumping a schema
> version every time when table descriptor was changed is necessary.
> The proposal is to split those concepts making them independent as they
> should be. The schema version should be bumped only when table columns are
> changed. The table version should be changed when table descriptor was
> changed.
> Actually, we can use CatalogTableDescriptor.updateTimestamp as a "table
> version" instead of getting a tableVersion field back. UpdateTimestamp is
> strictly monotonic as schemaVersion, but we don't require continuity.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
