What I’m trying to do:
A database wrapper that allows you to use sqlite3 instead anvil’s database without changing any app code. Upto 10x faster than existing anvil tables
What I’ve tried and what’s not working:
A wrapper that replaces app_tables functionalities, and a migration script, that can migrate full data in first run of the script.
I think the advantages would be for people who want the convenience of the built in app_table mechanisms coupled with the flexibility of direct local access to their data when needed without the requirement to run their own Anvil Server.
The primary advantage of using an sqlite wrapper instead of the anvil app_tables is that the bottleneck to the page loading speeds on anvil is the app_tables call, also if in the future a very big application wants to move to a different cloud than anvil app tables then moving certain parts of the application slowly will be easier and faster.
For me, the big win would be supporting standard SQL declarative data integrity checks, via triggers and foreign key enforcement. (Garbage in, garbage out…)
So far, I’ve been working on layers on top of Anvil for that. It’s doable, but a lot of work, especially when you want something that generalizes to tables and relationships not yet created.
when you run the migration script for the very first time, an sqlite database will be created on your local/cloud machine and that will have all the tables with the required schema in an sqlite file called local.db
If your targeting a specific application ( and it’s tables ) you must
edit the migration_script.py , see the TABLES_TO_MIGRATE list. That was needed for my app to work.
yes that is correct, if you don’t want to hard code the names of tables by hand just do it with a simple script that fetches the names of the tables from the anvil app and populates the list automatically, I needed to avoid migrating certain tables, that is why I prefer to hard code TABLES_TO_MIGRATE for now.