[
https://issues.apache.org/jira/browse/IGNITE-28907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Valuyskiy updated IGNITE-28907:
------------------------------------
Description:
CacheConfiguration currently handles repeated and mixed calls to
setIndexedTypes() and setQueryEntities() inconsistently:
* Mixing the two APIs can silently discard query entity metadata, including
explicitly configured indexes.
* Repeated setQueryEntities() calls append entities but silently skip those
whose value type is already present.
* setIndexedTypes() contains a guard intended to reject repeated calls rather
than replace the previous configuration.
It is suggested to introduce an explicit configuration contract:
* Disallow mixing setIndexedTypes() and setQueryEntities() on the same
configuration instance. Throw CacheException regardless of the call order.
* Repeated setIndexedTypes() calls replace the previously configured indexed
types and query entities.
* Repeated setQueryEntities() calls replace the entire query entities
collection.
* Passing an empty array or null to setIndexedTypes() clears indexed types and
query entities. Passing an empty collection to setQueryEntities() clears query
entities.
* Empty calls still establish the configuration API. clearQueryEntities() does
not reset that choice.
* Affinity key configurations derived by setIndexedTypes() replace existing
mappings for the same types while preserving mappings for other types. Empty
calls leave key configurations unchanged.
Internal query entity updates during cache initialization and schema
synchronization must use a separate replacement mechanism that does not change
the configuration API marker and preserves QueryEntityEx metadata.
*This intentionally changes the public configuration contract.* Applications
that mix the two APIs must use a single API, and applications that rely on
additive setQueryEntities() calls must provide the complete collection in the
final call.
was:
CacheConfiguration currently handles repeated and mixed calls to
setIndexedTypes() and setQueryEntities() inconsistently:
* Mixing the two APIs can silently discard query entity metadata, including
explicitly configured indexes.
* Repeated setQueryEntities() calls append entities but silently skip those
whose value type is already present.
* setIndexedTypes() contains a guard intended to reject repeated calls rather
than replace the previous configuration.
It is suggested to introduce an explicit configuration contract:
* - Disallow mixing setIndexedTypes() and setQueryEntities() on the same
configuration instance. Throw CacheException regardless of the call order.
- Repeated setIndexedTypes() calls replace the previously configured indexed
types and query entities.
- Repeated setQueryEntities() calls replace the entire query entities
collection.
- Passing an empty array or null to setIndexedTypes() clears indexed types and
query entities. Passing an empty collection to setQueryEntities() clears query
entities.
- Empty calls still establish the configuration API. clearQueryEntities() does
not reset that choice.
- Affinity key configurations derived by setIndexedTypes() replace existing
mappings for the same types while preserving mappings for other types. Empty
calls leave key configurations unchanged.
Internal query entity updates during cache initialization and schema
synchronization must use a separate replacement mechanism that does not change
the configuration API marker and preserves QueryEntityEx metadata.
This intentionally changes the public configuration contract. Applications that
mix the two APIs must use a single API, and applications that rely on additive
setQueryEntities() calls must provide the complete collection in the final call.
> Disallow mixing setIndexedTypes and setQueryEntities and use last-call-wins
> semantics
> -------------------------------------------------------------------------------------
>
> 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: MixedIndexConfigurationTest.patch
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> CacheConfiguration currently handles repeated and mixed calls to
> setIndexedTypes() and setQueryEntities() inconsistently:
> * Mixing the two APIs can silently discard query entity metadata, including
> explicitly configured indexes.
> * Repeated setQueryEntities() calls append entities but silently skip those
> whose value type is already present.
> * setIndexedTypes() contains a guard intended to reject repeated calls
> rather than replace the previous configuration.
> It is suggested to introduce an explicit configuration contract:
> * Disallow mixing setIndexedTypes() and setQueryEntities() on the same
> configuration instance. Throw CacheException regardless of the call order.
> * Repeated setIndexedTypes() calls replace the previously configured indexed
> types and query entities.
> * Repeated setQueryEntities() calls replace the entire query entities
> collection.
> * Passing an empty array or null to setIndexedTypes() clears indexed types
> and query entities. Passing an empty collection to setQueryEntities() clears
> query entities.
> * Empty calls still establish the configuration API. clearQueryEntities()
> does not reset that choice.
> * Affinity key configurations derived by setIndexedTypes() replace existing
> mappings for the same types while preserving mappings for other types. Empty
> calls leave key configurations unchanged.
> Internal query entity updates during cache initialization and schema
> synchronization must use a separate replacement mechanism that does not
> change the configuration API marker and preserves QueryEntityEx metadata.
> *This intentionally changes the public configuration contract.* Applications
> that mix the two APIs must use a single API, and applications that rely on
> additive setQueryEntities() calls must provide the complete collection in the
> final call.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
