$top and $skip are getting wrong ids for beginning and end

[DimitarPetrov]

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

[wog48]

Looks like the type converter is not respected during range determination

[wog48]

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?

[wog48]

After recreating my test data, I also get the error.

[wog48]

Solution is available with release 1.0.9.