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.