Exported table schema's in varying order

Just noticed that by bright idea the other night fell on its face. I want a simple mechanism to compare table schema’s across applications. My bright idea, perform schema export from both, and then perform a recursive diff against each extracted folder.

To my chagrin, no ordering is being applied to this export command it seems. Is this by design?

Might you guys have a quick script to get my outcome, of comparing application schemas.


Are you talking about the ordering of columns in the CSV files? I believe they come out of hashmaps, hence there is no particular ordering. I would suggest using admin API to get a list of tables, then make the following request to get the schema definition for each table in the list:



Mark, going through some of these details I found a peculiarity in the implementation. It didn’t make sense to require an appId for developer.backendless.com for endpoint /console/applications; especially doesn’t make sense when i’m asking for a full list of applications in my environment and i’m already authenticated.

What thinks’ ye’?

Charles, appId is not required for the /console/applications route. It is a request to get a list of all the developer’s apps. Here’s a list of all the headers for a request I just tried:


I see my problem, I had /3.x/console/applications. Using /console/application works as advertised. I believed though it was necessary for /3.x within the endpoint?

Funny enough, if i provided the key I got my applications back. False alarm there, maybe?

Sorry for continuing this thread, but asking questions and pointing out oddities as I put together this tool.

The most recent oddity:

Calling /console/applications returns a json array without ‘currentVersionId’ property
Calling /3.x/console/applications with a application id in header returns a json array with ‘currentVersionId’ property

Is this intended? Just curious.

/3.x/console/applications is the implementation from the 3.x version

/console/applications is the new route which returns a list of all apps (for both 4.0 and 3.x backends).

Since we got rid of the app versions in 4.0, the “currentVersionId” property is not returned in the /console/applications route, so, yes, it is intended.


My solution to this problem… Found here: