Avoid double retrieval

I think the answer is no, but still i’ll give it a shot
if i have, let’s say, a messages table with multiple refrences to one element in the persons table, whenever i query the messagess table it wll bring the same sender with each message object, thus using a lot of bandwidh with redundant information. is there a workaround for this without merging tables?

Do you query with JavaScript or other type of client?

Javascript

Your duplicate objects will be sent to the client as references. There will be only one instance serialized and others will be sent as pointers. In this case, the bandwidth and the processing speed should not be a concern. The important caveat here is that you should use our Backendless SDK for JS since it knows how to deserialize such a structure into JS objects.

Regards,
Mark

Alright, that sounds fantastic, thank you. i was concerned about it due to the fact that when i enabled auto load relations the size of the response greatly increased and i thought i was receving duplicates.

The payload has increased because of additional (related) objects included into the response.

i understand what you say, nevertheless i feel there is something missing.

i have a products table, with a 1 to N relation to a list table, this list table has objects with a 1 to N relation to Products (it has lists of dependent products)
I just made a test loading data from the product table, with auto loading on for list and off from list to products. it
transferred 129 KB. if i turn the autoload from list to products also, the load increases to 602 KB. However by constrain, the products loaded from the lists are the same as the ones loaded from the products table

could you provide your applicationId ?

Sure,

‘97F1E992-5230-CFC2-FF4D-58283C79C800’

Ok, now I understand the issue. We create ticket to optimize trafic and selection.