Hi,
I have a data table which gives me an “Internal server error with id ACAE99D4-6F88-ADCE-FF1F-1617D0E91F00” when I try to open it in the web console (the error ID changes each time I try).
When i query the table from REST using a GET operation, I mostly get an error 499: bad gateway. Sometimes I also get an internal server error, each time with a different ID.
Could this be caused by something I do wrong? The table does contain 1-to-1 relations to other tables, could that cause any problems? One relation is to a user that is created beforehand, and one relation is to a table and I create that object directly in the creation of the item (nested json).
I am busy migrating data from our old cloud backend so I can easily start fresh with that data, but in a couple of months the old cloud shuts down so I have to get it stable and robust by then.
Kind regards,
Jeroen
Hi Jeroen,
What is your application ID?
Hi, the application ID is C6730F91-F429-E4C9-FF61-ED62B2B2E100.
By now, I tried deleting all entries from the table (MotionOperators). That succeeded and the internal server error in the web console is gone. Maybe I should have left it alone for a while…
But the errors in the REST GET request are still there. GET request from within the REST console on the website does work (although there is no data, but it doesn’t give an error). Could it be my where clause? I did URL encode it properly (and I use similar where clauses in a lot of code that does work without problems).
Please, provide an example of the failing REST request. A curl example would be perfect.
If I just type the following in the REST Console for the MotionOperators table:
user.objectId = '7B2B116B-5772-8D85-FFB9-BD2E5DF0DC00'
I get “server temporarily unavailable” or an internal server error.
Note that access to the data is restricted to certain user roles, but the user that is logged in when doing the request has the right access.
Edit: I should not that when I don’t provide a where clause, the request does not fail.
The “user” relation of your MotionOperators table was corrupted in database, so I had to remove it. Please try again and tell us whether you receive any Internal Server Errors now.
Also to investigate this, did you remove or modify the “user” relation recently?
Hi,
Thanks for fixing it. I experimented with the table some month ago. At the time there were a lot of problems with the backendless servers. It could be that the relation got corrupted at that time.
Is there anything I can do to prevent this? If I let the table structure alone, should it not occur anymore?
If there are problems with relations, I could change everything to just use the object ID instead of a real relation. But relations give me a lot of advantages.
In order to be sure that nothing won’t break, I recommend you to omit the schema-changing operations in your application code. It means, that you should better define the schema in the beginning from console (which are your tables and relations between them) and then just use it without modifications (you may freely insert, update, find, remove etc. your objects, but don’t add/remove any relations or tables automatically).
We’re working on providing the most stable service with dynamic schemas and had a lot of success with that recently, but still there is a little chance that some automatic modification might go wrong.
Hi,
In our system, where request jsons are generated, it is hard to ensure we don’t add any new fields. No extra properties should be added though, but I need a way to debug that. I could use the REST API to query the scheme and write code to ensure only those fields are added if needed.
What would help is a flag to make the table’s structure “static”. When doing a POST/PUT request with unknown properties, an error could be returned or the properties could be ignored.
Should I also avoid adding a related object directly in one request? In this case, I do that for the relation to an item in the MotionSystems table. I could first add an item to the MotionSystems table and add a reference to that existing item instead.
On another note: some things still seem to be corrupted in the table. I added the user property again (relation to Users table) and recreated the items in the table, but noticed no user object was returned in queries.
The autoload checkbox is checked, but when I try to uncheck it, I get message “Column with name ‘user’ already exists. Please, choose a unique name for the column.”.
Edit: That last problem seems to have resolved itself: the checkbox was unchecked when reloading and I was successfully able to check it again.
We’re planning a major release soon, where the Data Service will be greatly improved. This will include your suggestion of “static” schema.
Thanks, I look forward to that release.
Everything seems to be working correctly now. You can mark this topic as solved (or can I do that myself?).
Kind regards,
Jeroen