[
https://issues.apache.org/jira/browse/IGNITE-17074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17074:
-----------------------------------
Description:
First of all, this requirement comes from the PageMemory component restrictions
- having an entire UUID for table id is too much for a loaded pages list.
Currently the implementation uses String hash, just like in Ignite 2.x. This is
a bad solution.
In Ignite 3.x configuration model, every configuration update is serialized by
design. This allows us to have atomic counters basically for free. We could add
a {{int lastTableId}} configuration property to a
{{TablesConfigurationSchema}}, for example, and increment it every time new
table is created. Then all we need is to read this value in all components that
need it.
Maybe we should even use it in thin clients, but that needs a careful
consideration. Originally, int tableId is intended to be used in storage
implementations and maybe as a part of unique RowId, associated with tables,
but that's only a speculation.
was:
First of all, this requirement comes from the PageMemory component restrictions
- having an entire UUID for table id is too much for a loaded pages list.
Currently the implementation uses String hash, just like in Ignite 2.x. This is
a bad solution.
In Ignite 3.x configuration model, every configuration update is serialized by
design. This allows us to have atomic counters basically for free. We could add
a {{int lastTableId}} configuration property to a
{{{}{{TablesConfigurationSchema}}{}}}, for example, and increment it every time
new table is created. Then all we need is to read this value in all components
that need it.
Maybe we should even use it in thin clients, but that needs a careful
consideration. Originally, int tableId is intended to be used in storage
implementations and maybe as a part of unique RowId, associated with tables,
but that's only a speculation.
> Create integer tableId identifier for tables
> --------------------------------------------
>
> Key: IGNITE-17074
> URL: https://issues.apache.org/jira/browse/IGNITE-17074
> Project: Ignite
> Issue Type: Improvement
> Reporter: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
>
> First of all, this requirement comes from the PageMemory component
> restrictions - having an entire UUID for table id is too much for a loaded
> pages list. Currently the implementation uses String hash, just like in
> Ignite 2.x. This is a bad solution.
> In Ignite 3.x configuration model, every configuration update is serialized
> by design. This allows us to have atomic counters basically for free. We
> could add a {{int lastTableId}} configuration property to a
> {{TablesConfigurationSchema}}, for example, and increment it every time new
> table is created. Then all we need is to read this value in all components
> that need it.
> Maybe we should even use it in thin clients, but that needs a careful
> consideration. Originally, int tableId is intended to be used in storage
> implementations and maybe as a part of unique RowId, associated with tables,
> but that's only a speculation.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
