$top and $skip are getting wrong ids for beginning and end
DimitarPetrov opened this issue · 4 comments
I have 5 entities with more related entities that are expanded.
If I do the query:
/systemInstances?$expand=consumptionBundles($expand=apis,events)
Everything is returned as expected with all the sub-entities.
However, If i execute the following query:
/systemInstances?$expand=consumptionBundles($expand=apis,events)&$top=9999999
I expect to see the same result, however this time only the systemInstances are returned with no sub-entities.
I think that is because the begin and end IDs are not calculated properly.
For example in logs I see:
[EL Fine]: sql: 2022-08-01 17:58:04.778--ServerSession(1198859194)--Connection(671796391)--Thread(Thread[http-nio-8080-exec-1,5,main])--SELECT DISTINCT description AS a1, product_type AS a2, base_url AS a3, system_number AS a4, name AS a5, id AS a6 FROM tenants_apps WHERE (tenant_id = ?) ORDER BY id ASC LIMIT ? OFFSET ?
bind => [3e64ebae-38b5-46a0-b1ed-9ccee153a0ae, 9999999, 0]
[EL Fine]: sql: 2022-08-01 17:58:04.815--ServerSession(1198859194)--Connection(1786415002)--Thread(Thread[http-nio-8080-exec-1,5,main])--SELECT DISTINCT t0.short_description, t0.id, t0.description, t0.name, t0.ord_id, t0.app_id FROM tenants_bundles t0, tenants_apps t1 WHERE ((((t1.id >= ?) AND (t1.id <= ?)) AND ((t1.tenant_id = ?) AND (t0.tenant_id = ?))) AND (t0.app_id = t1.id)) ORDER BY t0.app_id ASC
bind => [8ee0531c-44a5-403b-8409-338b7fe6ec77, 5eaaa231-6170-4064-84e8-84ef9fae363e, 3e64ebae-38b5-46a0-b1ed-9ccee153a0ae, 3e64ebae-38b5-46a0-b1ed-9ccee153a0ae]
Which indicates that the we query for entities that are with id >= 8ee0531c-44a5-403b-8409-338b7fe6ec77 and <= 5eaaa231-6170-4064-84e8-84ef9fae363e
However, If I execute the first query to get the systemInstances from my machine, the sorted list of their IDs is:
20a201e5-715e-4f27-bb33-008359b07c10
5eaaa231-6170-4064-84e8-84ef9fae363e
8ee0531c-44a5-403b-8409-338b7fe6ec77
9d8bb1a5-4799-453c-a406-84439f151d45
9e519b5c-274e-4415-b8e7-51b07bd07b60
Which means that the second query should bind with d >= 9e519b5c-274e-4415-b8e7-51b07bd07b60 and <= 20a201e5-715e-4f27-bb33-008359b07c10
Looks like the type converter is not respected during range determination
Hello @DimitarPetrov,
my first try to reproduce the problem failed. What DB do you use and what datatype do you use to store the UUIDs?
After recreating my test data, I also get the error.
Solution is available with release 1.0.9.