[
https://issues.apache.org/jira/browse/IGNITE-28907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Valuyskiy updated IGNITE-28907:
------------------------------------
Summary: Support merging QueryEntity metadata configured through
setIndexedTypes and setQueryEntities (was: Fail node startup when the same
query entity is configured through indexedTypes and queryEntities)
> Support merging QueryEntity metadata configured through setIndexedTypes and
> setQueryEntities
> --------------------------------------------------------------------------------------------
>
> Key: IGNITE-28907
> URL: https://issues.apache.org/jira/browse/IGNITE-28907
> Project: Ignite
> Issue Type: Task
> Reporter: Oleg Valuyskiy
> Assignee: Oleg Valuyskiy
> Priority: Major
> Labels: ise
> Attachments: MixedIndexConfigurationReproducer.patch
>
>
> h2. Problem
> Apache Ignite allows the same SQL value type to be configured simultaneously
> through:
> * {*}CacheConfiguration#setIndexedTypes{*}, which creates a *QueryEntity*
> from annotations such as *@QuerySqlField*
> * {*}CacheConfiguration#setQueryEntities{*}, which supplies a *QueryEntity*
> explicitly configured in the node configuration xml-file
> Ignite does not support merging these two query entity definitions. When both
> configuration mechanisms describe the same value type, the query entity
> registered first is retained, while the subsequently supplied entity is
> ignored without any warning. The node still starts successfully and the cache
> remains operational, but part of the configured SQL schema may be missing.
> For example, single-field indexes may be declared using
> {*}@QuerySqlField(index = true){*}, while a composite index for the same
> value type is configured through *queryEntities* in the node configuration.
> Depending on the order in which the corresponding setters are invoked, either
> the annotation-derived indexes or the explicitly configured indexes are NOT
> created.
> Reproducer: [^MixedIndexConfigurationReproducer.patch]
> Starting a node with such a partially applied configuration is unsafe. The
> configuration error must be detected before the cache is started.
> h2. Root cause
> Both *CacheConfiguration#setIndexedTypes* and
> *CacheConfiguration#setQueryEntities* store query metadata in the same
> internal *qryEntities* collection. When an entity with the same value type is
> already present, the incoming entity is treated as a duplicate and is not
> added (see {*}CacheConfiguration#setQueryEntities{*}):
> {code:java}
> for (QueryEntity entity : qryEntities) {
> boolean found = false;
> for (QueryEntity existing : this.qryEntities) {
> if (Objects.equals(entity.findValueType(), existing.findValueType()))
> {
> found = true;
> break;
> }
> }
> if (!found)
> this.qryEntities.add(entity);
> }{code}
> When the value type is already registered:
> * the existing and incoming entities are not merged
> * their fields and indexes are not compared
> * conflicting or additional metadata is not validated
> * the ignored configuration is not reported
> The first registered query entity effectively wins.
> h2. Expected behavior
> Ignite must reject a cache configuration in which the same value type is
> configured through both *indexedTypes* and {*}queryEntities{*}. The node must
> fail to start with a *CacheException* instead of silently ignoring one of the
> query entity definitions. The validation must not depend on the order in
> which the configuration setters are called.
> h2. Possible follow-up
> Support for combining compatible query entity definitions may be considered
> as a separate improvement. Such an improvement would require explicit merge
> and conflict-resolution rules for:
> * fields and field types
> * table names
> * aliases
> * key fields
> * index names and definitions
> * other QueryEntity metadata
> Until such rules are defined and implemented, fail-fast validation is
> prefered as opposed to starting a node with an incomplete SQL schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
