lallemand created CAY-2895:
------------------------------
Summary: Incorrect Lazy Pagination Comparison for BigInteger PK
Key: CAY-2895
URL: https://issues.apache.org/jira/browse/CAY-2895
Project: Cayenne
Issue Type: Bug
Components: Core Library
Affects Versions: 4.2.2
Reporter: lallemand
Fix For: 4.2.3
Attachments: image-2025-09-01-14-24-18-956.png,
image-2025-09-01-14-24-41-442.png, image-2025-09-01-14-26-02-296.png,
image-2025-09-01-14-26-35-313.png, image-2025-09-01-14-26-45-722.png,
image-2025-09-01-14-27-06-177.png, image-2025-09-01-14-27-12-756.png,
image-2025-09-01-14-27-27-432.png
Dears,
In the latest stable version ({*}4.2.2{*}), we are encountering an issue with
the *Lazy implementation* based on {{ObjectSelect<T>.pageSize()}} when the
table’s *primary key* is of type {*}BIGINT{*}.
----
*Steps to Reproduce:*
# Use {{ObjectSelect<T>}} with pagination ({{{}pageSize{}}}) on a table where
the primary key column is of type {*}BIGINT{*}.
# Allow the {{IncrementalFaultList}} in *cayenne-server* to populate elements.
# Insert a new item into the dataset.
----
*Technical Details:*
* The issue occurs in {*}{{IncrementalFaultList.class}}{*}, specifically
within the {{fillIn}} method, which initializes {{{}protected final List
elements{}}}.
* When processing a *BIGINT* database PK mapping, the type defaults to
{*}{{Long}}{*}.
* This works fine until a new item is added. At that point, the method
{{updateWithResolvedObjectInRange}} is called, which in turn calls
{{replacesObject}} (for one of six implementations).
In our case, the class *{{SimpleIdIncrementalFaultList}}* is used.
Example:
* {{objectInTheList}} → value: {{{}137{}}}, type: *Long*
* {{idSnapshot.get(pk.getName())}} → value: {{{}137{}}}, type: *BigInteger*
*!image-2025-09-01-14-24-18-956.png!*
Because of the type mismatch, the comparison fails, leading to the following
exception:
!image-2025-09-01-14-24-41-442.png!
As a result, the list contains a *Long* object instead of the expected
*ObjEntity* inside our lazy implementation{*}.{*}
----
*Proposed Fix / Workaround:*
I modified the {{replacesObject}} method to handle *BigInteger* correctly.
!image-2025-09-01-14-26-02-296.png!
* *First modification (blue section in my test code):*
_Not recommended._ This forces replacement regardless of match. I added it only
to bypass an unrelated bug I observed occasionally. This may indicate a deeper
issue in the pagination implementation that requires further investigation.
* *Second modification (red section in my test code):*
_Required for correctness._ This ensures that *BigInteger* primary keys are
compared properly with Long values.
While this fix works, I believe a more elegant solution should exist within
Cayenne’s type handling logic.
----
*Test Configuration:*
* *Databases:*
** Oracle !image-2025-09-01-14-26-35-313.png!
** SQL Server !image-2025-09-01-14-26-45-722.png!
* *Entities:*
** {{{}DbEntity{}}}!image-2025-09-01-14-27-12-756.png!{{{}{}}}
** {{ObjEntity !image-2025-09-01-14-27-27-432.png!}}
----
*Impact:*
This is a {*}critical issue{*}: pagination becomes completely unusable when the
primary key is of type {*}BIGINT{*}.
----
*Best regards,*
Anton L.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
