[
https://issues.apache.org/jira/browse/IGNITE-17041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-17041:
------------------------------------
Description:
Let's consider the following situaiton:
The first server node is started with the following cache configuration.
{code:java}
QueryEntity qryEntity = new QueryEntity(String.class, Person.class)
.setTableName("PERSON")
.addQueryField("id", Integer.class.getName(), null);
CacheConfiguration<?, ?> ccfg = new
CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setQueryEntities(Collections.singletonList(qryEntity));
{code}
Then we add the column manually like that:
{code:java}
srv.cache(DEFAULT_CACHE_NAME).query(new SqlFieldsQuery("ALTER TABLE PERSON ADD
data INTEGER")).getAll();
{code}
As a result we get query entity with the following fields -> aliases:
"id" -> "ID" (Note that isSqlEscapeAll flag is disabled in the cache
configuraiton so the Ignite automatically creates upper-case aliases for
preconfigured entities)
"DATA" -> "DATA"
Then lets start second server node with the following cache confiuration:
{code:java}
QueryEntity qryEntity = new QueryEntity(String.class, Person.class)
.setTableName("PERSON")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("data", Boolean.class.getName(), null);
CacheConfiguration<?, ?> ccfg = new
CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setQueryEntities(Collections.singletonList(qryEntity));
{code}
Note the type of "data" query field is Boolean now.
The mentioned above configuration will be processed as query entity with the
follwing fields -> aliases:
"id" -> "ID"
"data" -> "DATA"
Note that isSqlEscapeAll flag is disabled in the cache configuraiton so the
Ignite automatically creates upper-case aliases for preconfigured entities and
uses them as column names.
During the join process of the second node first node validates that cache
query fields configuration which configured on the second node is identical
with the local one. If there are unique fields that are not present in the
first node's config then configurations from both nodes are merged to
complement each other. If there are some conflicts (e.g. the same field has
diferent types for joining and "in cluster" nodes) joining node will be
rejected.
In the described above example second node joins the cluster with no conflicts.
Merge process completes succcessflully and we get two data columns - "data" and
"DATA".
Since isSqlEscapeAll flag is disabled for both configuration it's confusing
behaviour.
The expected behaviour is that the second node would be rejected.
was:
Let's consider the following situaiton:
The first server node is started with the following cache configuration.
{code:java}
QueryEntity qryEntity = new QueryEntity(String.class, Person.class)
.setTableName("PERSON")
.addQueryField("id", Integer.class.getName(), null);
CacheConfiguration<?, ?> ccfg = new
CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setQueryEntities(Collections.singletonList(qryEntity));
{code}
Then we create the column manually like that:
{code:java}
srv.cache(DEFAULT_CACHE_NAME).query(new SqlFieldsQuery("ALTER TABLE PERSON ADD
data INTEGER")).getAll();
{code}
As a result we get two query entities with the following aliases:
"id" -> "ID" (Note that isSqlEscapeAll flag is disabled in the cache
configuraiton so the Ignite automatically creates upper-case aliases for
preconfigured entities)
"DATA" -> "DATA"
Then lets start second server node with the following cache confiuration:
{code:java}
QueryEntity qryEntity = new QueryEntity(String.class, Person.class)
.setTableName("PERSON")
.addQueryField("id", Integer.class.getName(), null)
.addQueryField("data", Boolean.class.getName(), null);
CacheConfiguration<?, ?> ccfg = new
CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setQueryEntities(Collections.singletonList(qryEntity));
{code}
Note the type of "data" query field is Boolean now.
The mentioned above configuration will be stored as two query entities
"id" -> "ID"
"data" -> "DATA"
Note that isSqlEscapeAll flag is disabled in the cache configuraiton so the
Ignite automatically creates upper-case aliases for preconfigured entities and
uses them as column names.
During the join process of the second node first node validates that cache
query fields configuration from the second node is identical with the local
one. If there are unique fields that are not present in the first node's config
then configurations from both nodes are merged to complement each other. If
there are some conflicts (e.g. the same field has diferent types for joining
and "in cluster" nodes) joining node will be rejected.
In the described above example second node joins the cluster with no conflicts.
Merge process completes succcessflully and we get two data columns - "data" and
"DATA".
Since isSqlEscapeAll flag is disabled for both configuration it's confusing
behaviour.
The expected behaviour is that the second node wuld be rejected.
Environment:
was:
> Query fields merge process does not consider aliases to determine conflicts.
> ----------------------------------------------------------------------------
>
> Key: IGNITE-17041
> URL: https://issues.apache.org/jira/browse/IGNITE-17041
> Project: Ignite
> Issue Type: Bug
> Environment:
> Reporter: Mikhail Petrov
> Priority: Major
> Labels: ise
>
> Let's consider the following situaiton:
> The first server node is started with the following cache configuration.
> {code:java}
> QueryEntity qryEntity = new QueryEntity(String.class, Person.class)
> .setTableName("PERSON")
> .addQueryField("id", Integer.class.getName(), null);
> CacheConfiguration<?, ?> ccfg = new
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setQueryEntities(Collections.singletonList(qryEntity));
> {code}
> Then we add the column manually like that:
> {code:java}
> srv.cache(DEFAULT_CACHE_NAME).query(new SqlFieldsQuery("ALTER TABLE PERSON
> ADD data INTEGER")).getAll();
> {code}
> As a result we get query entity with the following fields -> aliases:
> "id" -> "ID" (Note that isSqlEscapeAll flag is disabled in the cache
> configuraiton so the Ignite automatically creates upper-case aliases for
> preconfigured entities)
> "DATA" -> "DATA"
> Then lets start second server node with the following cache confiuration:
> {code:java}
> QueryEntity qryEntity = new QueryEntity(String.class, Person.class)
> .setTableName("PERSON")
> .addQueryField("id", Integer.class.getName(), null)
> .addQueryField("data", Boolean.class.getName(), null);
> CacheConfiguration<?, ?> ccfg = new
> CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setQueryEntities(Collections.singletonList(qryEntity));
> {code}
> Note the type of "data" query field is Boolean now.
> The mentioned above configuration will be processed as query entity with the
> follwing fields -> aliases:
> "id" -> "ID"
> "data" -> "DATA"
> Note that isSqlEscapeAll flag is disabled in the cache configuraiton so the
> Ignite automatically creates upper-case aliases for preconfigured entities
> and uses them as column names.
> During the join process of the second node first node validates that cache
> query fields configuration which configured on the second node is identical
> with the local one. If there are unique fields that are not present in the
> first node's config then configurations from both nodes are merged to
> complement each other. If there are some conflicts (e.g. the same field has
> diferent types for joining and "in cluster" nodes) joining node will be
> rejected.
> In the described above example second node joins the cluster with no
> conflicts.
> Merge process completes succcessflully and we get two data columns - "data"
> and "DATA".
> Since isSqlEscapeAll flag is disabled for both configuration it's confusing
> behaviour.
> The expected behaviour is that the second node would be rejected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
