What would be useful is the ability to create schema from the REST api. The dynamic “on the fly” creation is brilliant but it doesn’t allow you to control data types - often floats are created when an integer is desired. Other aspects of schema can’t be done with dynamic creation.
Have I missed something? or could you put this on the agenda?
This is already possible using Admin API. This is the API used by Backendless console. Take a look at the request made by console in the Network tab of the browser’s developer tools.
Regards,
Mark
Thanks for fast response. I’m sure I can figure it out from here .
Having had a look at this - not sure if I’ve got this right - getting this error
{“code”:8002,“message”:“Could not parse request with message: , status code 404, headers POST /appkey/apikey/data/xyxyxy/columns”}
with a payload of {“dataType”:“INT”,“name”:“Fred”,“required”:false,“unique”:false,“indexed”:false,“defaultValue”:null,“customRegex”:null}
/appkey/apikey/data/xyxyxy - creates the table ok
Can you advise?
The routes starting with /appid/apikey/ are the API ones. The Admin routes are the ones your browser does when you navigate through the console. For example, here is a request to create a column, you can inspect it in browser’s developer console by clicking “New” and then “Create” on schema editing tab:http://support.backendless.com/public/attachments/36645dd6ec2e10e1710fd3bc3e0fc6b9.jpg</img>
Having got the above working - its not quite what I asked for in the first place! Can I summarise?
My very first “Idea” should have been specific.
REST API to support schema creation from user access.
I need to give my application control over creating schemas - it seems the only way of doing this is by giving out developer credentials and using the admin interface. Not only that - there are there are 2 different credential models using usertoken coming from data, or auth-key coming from response header - all a bit inconsistent in a way.
I don’t see why, on the face of it, this shouldn’t be a feature of the user api - since the user can create a table on the fly by allowing dynamic creation.
Thanks
Our initial idea was that you shouldn’t need the ability to operate on the schema level, instead you can and should use the object level. This also gives you performance benefit when you define your schema before your app goes to production and disable “dynamic schema definition” after that. The reason is that operating on schema (creating, and deleting tables and columns) requires synchronization and blocks any parallel operation on that same schema, which can also lead to deadlocks or your data model being corrupted.
It is possible, however, that we consider the schema editing API in the future. Though for now we have lots of other more significant ideas and tasks, so it’s not yet on our roadmap.
