chore: move streams change moves for list variable

[triceo]

Introduces ListChangeMoveProvider that is capable of generating change moves, assign moves and unassign moves.

To do that, several new capabilities are introduced to data streams, which mimic capabilities of constraint streams and use the same underlying Bavet nodes.

With the new value range work, nodes and data sessions no longer need initialization, because everything we need, we can now find in the value range manager.

[Copilot]

Pull Request Overview

This pull request introduces ListChangeMoveProvider that generates change moves, assign moves, and unassign moves for list variables. The implementation adds new capabilities to data streams and removes initialization requirements from nodes and data sessions by utilizing the value range manager.

• Adds comprehensive list variable move generation with support for assignments, changes, and unassignments
• Introduces mapping and distinct operations to data streams with new APIs
• Removes node initialization requirements and simplifies session management

Reviewed Changes

Copilot reviewed 80 out of 80 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
ListChangeMoveProvider.java	New provider generating list variable moves with filtering logic
DefaultSolverTest.java	Adds test for list variable solving with move streams
SolutionView.java	Adds countValues method for list variable length queries
AbstractUniDataStream.java	Implements map and distinct operations for data stream transformations
DefaultMoveStreamFactory.java	Updates constructor to accept EnvironmentMode parameter
Various move classes	Updates move implementations with better type safety and getter methods

Comments suppressed due to low confidence (1)

core/src/test/java/ai/timefold/solver/core/impl/solver/DefaultSolverTest.java:444

• Grammatical error: 'Only penalizes is length' should be 'Only penalizes if length'.

            }

[triceo]

The concern regarding distinct() is not well founded, for three reasons:

• This is an operation in the underlying Bavet network, and is fully incremental. (Under the hood, it is implemented using a GroupBy node.) It does have some overhead, but any Bavet node has overhead. In this case, the overhead is comparable to map, which does a very similar thing.

• CS uses the same underlying Bavet network, and its network is updated on every move. MS, on the other hand, only updates its Bavet network once at the end of every step. Therefore, if we assume that the performance of CS is sufficient, the performance of MS will be pretty much irrelevant, because it will be executed much less than CS.

• This is an implementation detail. If it ever proves insufficient, we will change the implementation of the provider. At the moment, I am worried about functionality and the programming model that we expose, not minor performance issues.

[zepfred]

The concern regarding distinct() is not well founded, for three reasons:

• This is an operation in the underlying Bavet network, and is fully incremental. (Under the hood, it is implemented using a GroupBy node.) It does have some overhead, but any Bavet node has overhead. In this case, the overhead is comparable to map, which does a very similar thing.
• CS uses the same underlying Bavet network, and its network is updated on every move. MS, on the other hand, only updates its Bavet network once at the end of every step. Therefore, if we assume that the performance of CS is sufficient, the performance of MS will be pretty much irrelevant, because it will be executed much less than CS.
• This is an implementation detail. If it ever proves insufficient, we will change the implementation of the provider. At the moment, I am worried about functionality and the programming model that we expose, not minor performance issues.

Thank you for the explanation. Having the GroupBy at the end of the step is indeed better than having it at the end of each applied move. However, if it is not necessary, avoiding it altogether is even better.

Nevertheless, I liked the functionality and programming model provided at this stage.

[sonarqubecloud]

Quality Gate failed

Failed conditions
54.2% Coverage on New Code (required ≥ 70%)

See analysis details on SonarQube Cloud