I have a service which was create while ago. It suddenly stopped working and the error seems to be a bit odd. The service is just using “Load Table Objects”, “Load Object Relations” and “Get Object Count”. Could you please advise what is this error code and whether something hasn’t been changed in the implementation on the backendless codeless side?
Below error:
400 - Unable to create relation. Unknown column name - ‘find’. Make sure the column is created first with the ‘column creation API’ or in Backendless Console. (1304)
The error implies that a relation is being created somewhere. How can we reproduce the error? Can we try invoking your service? If so, need the following info:
Hello @mark-piller - quick update on the issue. After a detailed investigation from our side, it seems that the issue occurs when Load Table Objects passes ID of the object in the url as serviceName/XXXXXX, where XXXXX is the objectID. It looks like some update has been done on the backendless side that has broken this.
Please note that the same call works fine from the REST console so it seems that the root cause is on the codeless side.
Below fragment of the code that has been built based on the codeless blocks.
(await Backendless.Data.of((String(‘Users/’) + String(this.request.context.userId))).find(Backendless.DataQueryBuilder.create().setProperties([’*’]).setRelated
Hope that helps to quickly investigate the issue and roll back the changes that caused it.
Yes, you are right, this is the issue. Recently we changed the find method in the JS-SDK (which is used in the Codeless logic), now it add /find at the of the URL and uses POST method.
As I understand you compose the table name {tableName}/{objectId} in order to load a single object along with its relations, am I right?
I just created a new internal ticket to add a new block FindById with all the related parameters, such as: relations, properties, etc. This should solve your problem.
While it is not done, you can add where clause objectId = '{YOUR_OBJECT_ID}' and then get the first element
Hello @vladimir-upirov is there a chance to keep the backward capability? It will take bigger effort to change each current service.
I was thinking about that workaround but again, this adds an effort to change all services and test them again. Additionally, can you please confirm whether this has any impact on the performance while using where instead of the previous “/{objectId}” approach?
I’m sorry but the backward compatibility is not broken, the find table objects block still works as it did before the fix. In your case, this is more like a hack, instead of a table name you attach it with an objectId.
According to the performance, I believe it works much faster when you request an object by its id directly, however, we are going to add a new codeless block for this asap.