Support Topics Documentation Slack YouTube Blog

Paging size (and loadRelationsQueryBuilder)

Hello
I have Table A that has 1:N Relation with Table B. I know that if I want to get all the related data for an entry in table A I do the following ( I have no more than 100 related items per entry):

LoadRelationsQueryBuilder<Map<String, Object>> loadRelationsQueryBuilder;
loadRelationsQueryBuilder = LoadRelationsQueryBuilder.ofMap();
 loadRelationsQueryBuilder.setRelationName( "titles" );

 List<Map<String, Object>> relatedObjects;
 relatedObjects = Backendless.Data.of( "A" ).loadRelations(
                    albumObjId,loadRelationsQueryBuilder );

I have 2 questions:
1- It says the default number of related data is 10. If I do loadRelationsQueryBuilder.setPageSize(100); then do I get 100 related data? 10 is too small for any list especially if it was grid video of texts

2- I can’t find in documentation how to do subsquent calls for next page. Do I I just call again

relatedObjects = Backendless.Data.of( "A" ).loadRelations(
                    albumObjId,loadRelationsQueryBuilder );

and the loadRelationsQueryBuilder is smart enough to know where to continue from last time and when it hit the max?

Thank you

Hi.
For your purposes and according to your example you can use methods prepareNextPage() and preparePreviousPage() respectively.

If you have really a huge amount of related data to one record i would also recommend just to get the parent objectId (in your case – table “A”) and then use ordinary find() apicall with where clause a[title_column].objectId = 'objectId_from_a'.

Here is the link to the documentation:
https://backendless.com/docs/android/data_data_paging.html

Hi Mark,
The link you shared has no mention of LoadRelationsQueryBuilder . It only mentions DataQueryBuilder. I understand there could be multiple ways to do the same thing (or maybe not!) but I am trying to use what is said under the Relation documentation

Hi Oleg,
Thanks for your message. Alright so I just call prepareNextPage and then I do the query again. I guess I will keep doing that till the returned page size is the less than the page max size, right?

What about my question in point 1. Can I set the page size for the initial return?

I don’t think 100 data points is considered huge at all but thanks for the suggestion. However if I do that then I will lose the order of the items. (When I set the 1:N related data, the order of the data matters to me in the order they were inserted). Unless you have a solution for that

Thank you

Sorry, I missed it that you’re paging through relations. We need to update the doc to reflect that.

As for the page size for the relations, it is also controlled with the pageSize argument.

Perfect so I can set the initial page size for the first query (to under 100) and it does not have to be stuck at 10.

Just as suggestion, I totally get why you guys went from returning unlimited data to limited. I think this is great performance improvement decision but I think you went from one extreme to another . 10 related points is a very small value. Loading a Grid of text is more than 10 items. So essentially often a developer ends up doing multiple queries at once or not do it at all. I am sure you saw the multiple posts about the hard time faced with this on this forum. I think it would be great to limit it to 100 (or even 50) as that is still small data set and serve a lot of the display issues. Typically a user has to scroll 2-3 times to start the loading screen again. No developer likes to start the “loading screen” on the first scroll touch. The 100 points will enable that.

If the reason is monetary then count calls with “Boolean:biggerSet” as 2 calls and queries with less data set as 1 call.

I just thought I would share my suggestion

PS: I know I can create custom logic that does the 2 queries and return to me one query. But A) it is still 2 roundtrips to the database and B) that’s extra work on the developer that is needless to take place as it is BaaS solution. Now if someone wants more than 100 then that is a large set and warrents the server coding

Happy Monday!

Thanks for the feedback. We do not limit it at 10, the limit for Backendless Cloud is 100. A developer can modify the page size and set it between 1 and 100 to a value that makes sense for their app. The reason we set it at 10 is we wanted to bring developer’s attention to the fact that data is paged. If we default it to 100 a lot of people will assume that they get all their data and would release their apps with that assumption.

Hope this makes our rationale clearer.

Cheers,
Mark

You are the best!!! THANK YOU . This is definitly what I am looking for