For App backup purposes, I just did “Download as a File”

- This includes both regular (
db_schema
) and extended (exported_table_schema
) table definitions. But I have multiple databases.
- It includes source code. But I have multiple branches.
Just so that I don’t get mixed up, which of these contributed to that .yaml file?
It’s the branch you currently have open (so, dev_m...
for you
)
Thanks, @meredydd! That answers #2.
Still not sure about question #1. If I had to guess, I’d say it was either
- the Default Database, or
- the currently-selected DEBUG Database.
Right now they have the same structure, so it’s not easy to tell at a glance. If I dug into the table ID numbers…
The app source code contains the schema – that is, the shape of tables the app is expecting, not directly linked to any particular table. The idea is to document, in a machine-readable way, "this app’s code expects a users
table with an email
column (text) and an enabled
column (boolean), and a todo_items
table with name
(text) and done
(boolean) and owner
(link to the users
table).
When you switch databases, the Anvil editor will check whether your app’s expected schema matches the selected development database – if not, you’ll get the “Schema Mismatch” error, which invites you to say either “the database is correct” (thereby updating the source code’s schema to match) or “the source code is correct” (thereby editing the database until it has the same tables and column as the app is expecting).
The app schema is, of course, also how the standalone App Server knows to create the correct tables when you launch it!
1 Like
Thank you, @meredydd, that describes the db_schema
entry in the file.
The .yaml file also has an exported_table_schema
section. This is of interest because this app has multiple databases, and the ability to share tables between databases and apps. Numeric table IDs appear here, and in row ids, so this can help disambiguate which physical table is being used by which database – if only I knew which database it was drawing from!
These IDs had to come from one of my 3 databases. I’m just not sure which one, because at the moment, my Default Database and my DEBUG database are the same database.
Edit: for future readers, I’ll clarify the original question.
Edit 2: Changing the DEBUG database setting does not change the resulting .yaml file. This favors the Default Database hypothesis.
Edit 3: Downloading a table as CSV from the Default Database produces matching table IDs in the CSV’s row IDs. Downloading the same-named table from one of my other databases does not.
Conclusion: it’s the Default Database that is expressed in the exported_table_schema
section.
Ah, yes – exported_table_schema
is a legacy format, kept around only for the sake of old versions of the App Server and the Classic Editor. Expect it to be retired soon!
1 Like