[rezataroosheh]

JIRA: https://issues.apache.org/jira/browse/IGNITE-29226

What

A ContinuousQueryWithTransformer on a keep-binary cache (withKeepBinary()) now delivers the transformer's result to the listener as it was returned, for both local and remote events. Before this fix, a remote event whose transformer returned a user class (for example PersonId) arrived as BinaryObject, while a local event arrived as PersonId. A transformer that returns a BinaryObject still delivers a BinaryObject.

Why

On the remote node, CacheContinuousQueryHandler#transformToEntry wraps the transformer result into a cache object and copies the cache entry's keep-binary flag into the new entry. On the listener node, CacheContinuousQueryEvent#getValue unwraps the value using that flag, so the result stayed binary. The flag describes the cache entry, not the transformer result. It was reported on the dev list.

The fix sets the keep-binary flag of the transformed entry only if the transformer result is a BinaryObject, and clears the copied flag bit otherwise (CacheContinuousQueryEntry#removeKeepBinary). This matches the local path, where the listener gets the transformer result directly.

Compatibility: code that reads remote transformed events of a keep-binary cache as BinaryObject will now get the transformer's own result class, the same as for local events. Such code can return a BinaryObject from the transformer.

Related: IGNITE-29227 (same reporter, events held on an ATOMIC cache).

Tests

CacheContinuousWithTransformerKeepBinaryTest, with two server nodes, a TRANSACTIONAL cache, one key whose primary is the query node and one whose primary is the other node:

• testNonBinaryResultArrivesAsIs: a transformer returning PersonId delivers PersonId for both events. It fails without the fix (the remote event is a BinaryObjectImpl).
• testBinaryValueResultArrivesAsIs: a transformer returning the binary value delivers BinaryObject for both events.
• testBinaryKeyResultArrivesAsIs: a transformer returning the binary key delivers BinaryObject for both events. PersonId.id is @AffinityKeyMapped, so a PersonId key has the same primary node as its id.

The cache is TRANSACTIONAL on purpose: on an ATOMIC cache, IGNITE-29227 would interfere, since the result class is not registered yet.

The Contribution Checklist

• There is a single JIRA ticket related to the pull request.
• The web-link to the pull request is attached to the JIRA ticket.
• The JIRA ticket has the Patch Available state.
• The pull request body describes changes that have been made.
  The description explains WHAT and WHY was made instead of HOW.
• The pull request title is treated as the final commit message.
  The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
• A reviewer has been mentioned through the JIRA comments
  (see the Maintainers list)
• The pull request has been checked by the Teamcity Bot and
  the green visa attached to the JIRA ticket (see tab PR Check at TC.Bot - Instance 1 or TC.Bot - Instance 2)

Notes

• How to Contribute
• Coding abbreviation rules
• Coding Guidelines
• Apache Ignite Teamcity Bot

If you need any help, please email dev@ignite.apache.org or ask any advice on https://the-asf.slack.com #ignite channel.

[github-actions]

Possible compatibility issues. Please, check rolling upgrade cases

This PR modifies protected classes (with Order annotation).
Changes to these classes can break rolling upgrade compatibility.

Affected files:

• modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryEntry.java
• modules/core/src/main/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryHandler.java