Support Topics Documentation Slack YouTube Blog

Database response "objectref" fields

(Jonas Eberhard) #1

Hello Guys,

I noticed with the growing size of my database responses, the number of “___objectref” fields in the json structure rises. These are always there instead of loaded relations. It seems this field replaces a related object which was already previously in the return string from the database.
In my mail you can find a response from my API fetched over the Backendless Console which gives this command:

-X “GET” “

-H ‘Content-Type: application/json’ \

-H ‘Accept: application/json’ \

-H ‘user-token: 531BC87D-C621-7D37-FF64-D6DE596B9F00’

I hope you can fix this or give me a hint how I can avoid this, as this stops my logic and GUI from working properly, as there are obviously data missing in the json tree where the program expects the omitted objects.

Thanks and Best regards

(Sergey Chupov) #2

Hi Jonas,

Are there any cyclic references in the response object? If there are, there is no other way to return such an object than to replace them with references.
Also, do you have any JS event handlers which interfere this exact request?

(Jonas Eberhard) #3

Hi Sergey,

yes, there is a custom JS cloud code handler. This checks some permissions of the user and then reads the data from the database and returns them without modifying any data.

No, there are no cyclic references. This is the sceme of the actual relations:

    CrtData: Objects in an extra table with more relations User: is the entry in the Users table UserVariables: Additional data in extra table without any further relations

| _______________ | __________________ | 
CrtData _______ UserVariables _____ User 

| _______________________ | 
Company _____________ User 

Poorly the forum ignores preformatted text, so ignore the underscores

The user relation from Scan and CrtData points in most cases to the same user, but can differ.
It seems that as soon as a user object once occured in the data, all other relations are replaced by an objectref field.

Attached is a file with the data structure returned by the database. Hope this clarifies things a bit


Scans Data Structure.txt (717B)

(Jonas Eberhard) #4

Any updates on this problem? Poorly it’s a complete show stopper for our application when the corresponding data for the relations are not in the json response…

(Jonas Eberhard) #5

In the meantime, I tried the Data Rest API. There it is the same behaviour, objects which appear multiple times in the data, are replaced by the tag “__originSubID: <GUID>” and the first occurence of this object gets an additional field: “__subID: <GUID>”.

In the data returned by the Cloud JS code the object is, as mentioned in my first post, replaced by the tag “___objectref: <ID>”, but the first occurence of the object does not get any new identifier.

(Jonas Eberhard) #6

I tested now a bit further the difference between the REST API and the Cloud JS code in my handler.

This is the curl command I use to get data from the

curl -X GET -k -H 'user-token: &lt;token&gt;' -i '<app>/&lt;key&gt;/data/&lt;tablename&gt;?loadRelations=CrtData,User,UserVariables&relationsDepth=2'

With that command I get the above mentioned “__originSubID” in the first occurence and the “__subID” fields instead of the original object

To test the cloud JS code, I created an extra handler in my app:

* @route GET /testdataread
* @returns {Object}
async testdataread()
var RelationsList = ['User', 'CrtData', 'UserVariables'];

var WhereClause = 'CompanyId = 4 and Deleted = false';

return (await Backendless.Persistence.of('eightcloud_AcquisitionMetaData').find(Backendless.DataQueryBuilder.create().setWhereClause("").setRelated(RelationsList).setRelationsDepth(2).setSortBy(["ID DESC"]).setPageSize(100).setOffset(0)))

This gives me the same data, but instead of the original related object, I only get the “___objectref: <ID>” field. And the first object occurence of the related does not get any additional reference field to identify the object as the ID of the “___objectref: <ID>” replacments.

(Vitaly Vengrov) #7

Hey Jonas

Please take a look at this utility module which is able to transform __objectref fields back into referred objects
Just integrate that module into your project and use its parse function instead of JSON.parse

(Jonas Eberhard) #8

Hi Vitaly,

how can I integrate that? With npm? Or just copy the code?

And what shall I pass for the “classMappings” parameter of the parse function?


(Sergey Kukurudzyak) #9

It is available for you if you are using the js coderunner or you can just copy the code

(Vitaly Vengrov) #10

Just copy the code. Don’t pass second argument

(Jonas Eberhard) #11

Very nice, thank you both.

I copied the file to my application code and do:

var BackendlessUtilJson = require('./Backendless.Util.Json.js');

DbData = BackendlessUtilJson.parse(JSON.stringify(DbData));

This resolvs all the __objectref fields :slight_smile:

Sergey, how should it be available when I use coderunner? The code I do this in, is my business logic code of my application. So I guess it runs in the coderunner. Would be more elegant to use the Backendless lib then.

(Sergey Kukurudzyak) #12


I’ve made mistake it is not available fro coderunner, you have to copy this code

(Jonas Eberhard) #13

Ok, alright. No problem.

Then you can mark this topic as solved.