you mention using a table id (integer), where I’m used to using a table name (local python name of a table).
Table names are not unique, across multiple apps and databases, and so cannot be used to reliably identify a table in any of my homebuilt tracking systems. But table idsare unique, so they are reliable.
Does anyone know how I can reliably get Anvil’s table id for every one of my tables?
All my apps, all their databases, even those with no Uplinks, no Environments, no local Git repository to inspect. Not all of them need one, and it’d be tedious to create them just for this purpose.
You could try exploring what happens when you click on the “Data” icon on the left of the IDE. When you click there, the list of tables is loaded in the IDE and it contains both table names and the links I showed in the snapshot.
I had a quick look, and didn’t notice any network traffic when clicking on it, which makes me think that the list is build on the client side rather than being fetched on demand. Soo… you could try to look at what happens when you open an app in the IDE, and see if you get the list of tables then? Good luck with that!
Or you could use Playwright to open the app in the IDE, then click on the “Data” icon, then dig into the DOM and find the info you are looking for.
And obviously, after you figure this out, the next update to the IDE will send you back to the reverse engineering table.
Some months back, I did check the downloadable full-app .yaml file, but the table ids there are just for the Default Database, and even those are going away (if they haven’t already).
I suspect that Anvil’s using a browser storage api for these data. But as you say, that’s all subject to change without notice, anyway.
At this point, your first response is the most reliable, so I’m glad for that. Thanks.
But my goal is to get the big picture, track every table I’ve got, so that I can do management, modelling, monitoring, and automation across all of them. Certainly for those which share tables. And to catch those which might unintentionally share tables.
Your technique can work. Thinking this through, I just have to
add code to run against every table, in every app I’ve got.
But I guess I could write a Dependency for that, and add it to each of the Apps.
It has to be able to temporarily add a row, when the table is empty.
In a Transaction, that deletes the row, so that other running instances of the same App don’t see the bogus row and get confused.
It has to work for Apps that have multiple Databases, not just the Default Database, even with no Environments defined, therefore no Uplink codes, so triggering it is an addition to the user interface, and switching to another database is another manual step … hmm…
Maybe I’ll have to give those an Environment after all, one per Database, so that they can respond to Uplink calls, and query each Database. Then an Uplink program could cycle through all the Uplink codes…
Okay, getting a reliable ID for every table I own is technically feasible. But as you can see, it’s a fair bit of work.
That would pay off, in the long run. Once all the setup work is done, I can run my Uplink program on a regular basis, making sure that my multi-app database model stays up-to-date.
The result would be something like Oracle’s standard VIEWs (e.g., USER_TABLES), that I used to query, to get all those details. In my Oracle days, I could (and did) layer over them with my own tables, adding app-level details that Oracle would not (and should not) know on its own.
No doubt our Anvil friends have VIEWs like that in mind for down the pike. It’s just that very few of us have multi-app systems of this scale, in mind, to track and manage, and they have so much more to do, for so many more developers. Modifying a system while keeping it running can only be a monstrous task, and I appreciate ALL their efforts to make and keep Anvil a reality.
