You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current binder module design, ShardingSphere uses the reflection of SQLStatement to create a new SQLStatement object and sets the relevant metadata information.
The main purpose is to avoid incorrect values in the SQLStatement cache object after the metadata is modified by DDL.
In the current design, the drawbacks are:
Using reflection to reset SQLStatement leads to code duplication.
There is a risk of omitting properties that were forgotten to set.
It requires SQLStatement to provide a no-argument constructor, which affects the flexibility of the design.
I would like to redesign it to put the SQLStatement after binding into the cache. This design can resolve the 3 drawbacks mentioned above, but at the same time, it introduces 2 new challenges:
After the metadata is modified, it is necessary to update the cached results after binding.
The same SQL for different databases needs to be distinguished.
I hope to update the cache design by using the database names + table names + updated version + SQL as the Key, and keep the Value as SQLStatement unchanged.
The core process is as follows:
Create new TableRegistry class, which only contains a Map field, with the key being "database.table" and the value being the updated count (version).
Each time a DDL is executed, update the version of the corresponding table in TableRegistry and persist into reg center.
Create new SQLStatementCacheKey class, including fields such as String databaseName, Collection<String> tables, Collection<Integer> tableVersions, and String sql, and override equals method.
Update the SQLStatement cache, changing the key from String to SQLStatementCacheKey.
When updating the cache, fetch table names from SQLStatement and table versions from TableRegistry to be included together in the SQLStatementCacheKey.
This discussion was converted from issue #31991 on July 17, 2024 04:11.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In the current binder module design, ShardingSphere uses the
reflection
of SQLStatement to create a new SQLStatement object and sets the relevant metadata information.The main purpose is to
avoid incorrect values
in the SQLStatementcache
object after themetadata is modified by DDL
.In the current design, the
drawbacks
are:I would like to redesign it to put the SQLStatement after binding into the cache. This design can resolve the 3 drawbacks mentioned above, but at the same time, it introduces 2 new
challenges
:I hope to update the cache design by using the
database names + table names + updated version + SQL
as the Key, and keep the Value as SQLStatement unchanged.The core process is as follows:
TableRegistry
class, which only contains a Map field, with the key being "database.table" and the value being the updated count (version).TableRegistry
and persist into reg center.SQLStatementCacheKey
class, including fields such asString databaseName
,Collection<String> tables
,Collection<Integer> tableVersions
, andString sql
, and overrideequals
method.String
toSQLStatementCacheKey
.table names
from SQLStatement andtable versions
from TableRegistry to be included together in the SQLStatementCacheKey.Beta Was this translation helpful? Give feedback.
All reactions