[
https://issues.apache.org/jira/browse/IGNITE-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10309:
-------------------------------------
Description:
Currently users may specify affinity key in {{CREATE TABLE}} command. However,
there are situations when custom affintiy function or custom affinity mapper
are used. In this case we do not know what actual fields are used for affinity
calculation, neither we know if two affinity functions are equal and produce
deterministic results *. In this case we may want to give user ability to
confirm on his own risk that certain caches has the same affinity functions and
are co-located.
To achieve this all we need is to add new string parameter, say,
{{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
function, we may compare their affinity functions keys. If they match, then we
may treat them co-located and extract partitions successfully.
\* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
{{FairAffinityFunction}} which depend on cluster history and may produce
different distributions between two caches even if two caches has the same
function parameters.
was:
Currently users may specify affinity key in {{CREATE TABLE}} command. However,
there are situations when custom affintiy function or custom affinity mapper
are used. In this case we do not know what actual fields are used for affinity
calculation, neither we know if two affinity functions are equal and produce
deterministic results *. In this case we may want to give user ability to
confirm on his own risk that certain caches has the same affinity functions and
are co-located.
To achieve this all we need is to add new string parameter, say,
{{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
function, we may compare their affinity functions keys. If they match, then we
may treat them co-located and extract partitions successfully.
* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
{{FairAffinityFunction}} which depend on cluster history and may produce
different distributions between two caches even if two caches has the same
function parameters.
> SQL: Ability to specifiy affinity function equality during table creation
> -------------------------------------------------------------------------
>
> Key: IGNITE-10309
> URL: https://issues.apache.org/jira/browse/IGNITE-10309
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Vladimir Ozerov
> Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> Currently users may specify affinity key in {{CREATE TABLE}} command.
> However, there are situations when custom affintiy function or custom
> affinity mapper are used. In this case we do not know what actual fields are
> used for affinity calculation, neither we know if two affinity functions are
> equal and produce deterministic results *. In this case we may want to give
> user ability to confirm on his own risk that certain caches has the same
> affinity functions and are co-located.
> To achieve this all we need is to add new string parameter, say,
> {{AFFINITY_FUNCTION_KEY}}. Then, if we meet caches with unknown affinity
> function, we may compare their affinity functions keys. If they match, then
> we may treat them co-located and extract partitions successfully.
> \* Remember our {{RendezvousAffinityFunction}} which is stateless, and old
> {{FairAffinityFunction}} which depend on cluster history and may produce
> different distributions between two caches even if two caches has the same
> function parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
