If one of the operations in a transaction fails, then the server returns an error object which contains a message. However, this object does not contain an error code. This makes it more difficult to check for and handle specific errors in client applications. Is this intended, a bug, or am I missing something?
Doesn’t the individual operation that failed contain the error code?
Hey @mark-piller, this is what I get as a response from the server. Am I missing something here?
No, you are not. I thought the error code would be there.
I am curious, what good would the error code in that specific case do? The error points out a problem in the logic I believe (you’re using a non-existing object).
In this case I was testing the server response if the client was using a non-existing object (which can happen as my client app may not be aware that the object no longer exists).
I want to set logic on my application which depends on the error code returned by the server, as I can predict and therefore want to handle the most common errors.
While I can use the opResultId to determine which operation failed, I cannot tell what exact error caused the operation to fail unless I match the message string, which doesn’t feel right.
Out of curiosity, what does the user do in the app where a situation of relation establishment with a non existent parent becomes possible?
Multiple users can have access to and manipulate the same records using their respective apps, leading to multiple scenarios. One such scenario is when one user has deleted a record that another user is attempting to edit (e.g. by setting a relation).
I see, makes sense. Have you thought of integrating our real-time database to prevent that specific scenario? When an object is deleted by one user, it should disappear for other users.
Yup absolutely. However as you may already know we are using AppGyver as our front-end development platform, which at the moment does not allow us to integrate with the JS SDK (or any other third-party library for that matter). This means we are stuck for now to using the REST API, which as far as we know does not support websockets or the real-time database.
AppGyver does support React Native websockets, however it is not clear to us how we could use that to connect to the Backendless real-time database. It seems as if we would need to develop an RT client similar to the one used by Backendless, which would be too expensive for us at the moment (and anyway the client also uses third-party libraries, which again, we can’t use yet!)
Should’ve gone with UI Builder, real-time database would not be an issue…
That’s pretty much the case! However, while we are definitely loving Backendless for our back-end needs, AppGyver’s UI (creating logic through diagrams by moving and connecting nodes with inputs/outputs in a blank canvas) feels much easier to understand and more comfortable to use as visual programming tools than UI Builder and Codeless Blocks. Just an honest opinion
Going on a bit of a tangent here, but also out of curiosity is there a specific reason why only the SDKs have support real-time database and not the REST API?
It is a matter of preference, I do not find diagrams to express that kind of logic friendly. They are great for describing process workflows, but not the type of behavior we’re discussing (IMHO).
REST is based on the
request/response principle. You send a request to the server - get a response. A real-time database requires a dedicated connection where the server pushes real-time events to the connected clients. As a result, REST can’t fit into that format of data exchange.
I agree is a matter of preference, although given our priorities, if we could somehow port all of our work from AppGyver to UI Builder without having to redo it all from scratch there, we definitely would! (side note, it isn’t clear to us whether we can build native mobile apps with UI Builder)
Fair enough, but why not expose an endpoint to allow connections through websockets? Or does such endpoint already exist and I missed it somehow?
Such an endpoint exists and all the logic of working with it is in our (open source) SDKs.
Porting your AppGyver implementation to UI Builder is possible, however, you would not be able to reuse anything.