Hi again guys,

I have a tricky situation where I use the TypedListDAO function GetMultiAsDataTable which beside others also gets the following 2 params: pageNumber and pageSize. Using these is a great way to implement pagination, except that I'm in the following situation where it fails:

I have to return exactly 10 results per page. On the first page (results 1 -> 10 of n) it is possible to show featured items - three at most, on the first positions. These featured items are the result of a secondary query, because there's no way to get the complete list of n items correctly ordered with one single query.

unfortunately with the current construction of the GetMultiAsDataTable function I do not see any possibility to correctly do this feature. In case of 3 featured items for example, on the first page I can get the required non-featured items by calling GetMultiAsDataTable(..., 1, 7) where 1 is pagenumber and 7 is pagesize. On the second page I have a problem, because if I show the results using GetMultiAsDataTable(..., 2, 10) then there will be 3 items (positions 8,9 and 10 of n) in the recordset which will never show up in the results.

Is there any way to specify a pageOffset param somewhere through which I could get back the items from 8 -> 17 instead of 11 -> 20?

If there is no such thing then is it planned to be included in LLBLGen 3?

Thanks again in advance guys!

P.S. I'm using LLBLGen 2.6 Final (Apr. 15)

Not supported and I don't know if it will be in V3. So, I think you have to find a workaround. Maybe just making the first page of 13 (your 10 + your 3 featured) and then pages of 10.

This requires skipping, which is unfortunately not a feature of our framework. Our paging system is based on 'page size + pagenumber', not 'skip n, take m'. We've toyed with several api designs for this, but it's awkward as both systems take 2 integers... We already have a take parameter (MaxNumberOf...) so we could create a workaround by specifying the skip amount as pagesize and leave pagenumber to 0, but it's awkward, and not natural. Another way is to add another overload, but that too is a bit awkward are there are already a lot of overloads (for example the collection fetch methods). I can't promise anything, but we'll re-evaluate this for v3.

You could solve your problem though: for page 2-n of 10 items, add a second predicate, a FieldCompareRange predicate, and use it to add a NOT IN (...) predicate to the query, where you add all id's of the first page (all 10, so 3 featured + the 7 non featured) as the range and set Negate to true to create the NOT IN ().

Then simply specify again page 1 for page 2 as all data of the original page 1 is omitted by the NOT IN predicate.

It's a workaround, though it will solve your requirement.