Wappler Version : v7.1.2
Operating System : Windows 11
Server Model: Local
Database Type: none
Hosting Type: none
I'm experiencing an issue when adding SQLite to a desktop project in Wappler (using Electron).
When I try to select an existing .sqlite3 file or create a new one, Wappler shows an error asking for the project path. Even after saving and trying to ignore this message, the database appears to be added — but then it behaves strangely.
When I create tables and run the synchronization, everything seems to be saved. However, after reloading the project or reopening the database view, all tables disappear, as if they were never created.
It seems like the SQLite file is added, but not correctly linked to the project or the Electron local environment. Has anyone experienced this before or knows a workaround for this issue?
You clicked Yes on the Refresh Button before saving the changes. This erased the changes as mentioned in the "Unsaved Changes" dialog.
You must click the Up arrow icon to save the changes. If you do this after the above action there are no changes as they were "erased" from the staging area.
[quote="kfawcett, post:2, topic:63946"]
You must click the Up arrow icon to save the changes. If you do this after the above action there are no changes as they were "erased" from the staging area.
[/quote] You're right — I made that mistake initially, but I corrected it and the issue still persists.
When I click the arrow to save, the process doesn't seem to complete properly. If I refresh in the correct order, the table I just created disappears. The problem is that Wappler displays the database in the interface, but it doesn't actually create or persist the structure.
Interestingly, I was only able to make it work yesterday by manually typing the SQLite file path (e.g., "/file.sqlite3") instead of using the UI buttons to open or add the file — as shown in tutorials and documentation. It seems the interface doesn't handle file selection correctly in this context.
An important observation: this issue only occurs in desktop/Electron projects. I ran the same steps in a web project with Node.js and everything worked perfectly. So far, these bugs seem to affect only Electron-based desktop projects — at least in my experience.
Also, this is the second major issue I’ve encountered with desktop projects. The first one happens when creating a new Electron project: it only initializes correctly if I previously opened an existing, working Electron project (one that was created properly). I mentioned that issue in another post, but unfortunately, I didn’t record a video at the time.
It's a known bug where the schema doesn't immediately refresh using the top refresh icon. Your issue is still that you clicked refresh and then yes, instead of first saving the schema/changes by clicking the up arrow, naming the change, and clicking save. The Database Manager only creates a migration file while adding/updating tables and fields. It's only once you click the up arrow that it applies the changes from the migration file to the database. If you refresh before the changes are applied, you lose them.
I've been building an Electron app for a while and have ran into these same issues, but it works well once you figure out what not to do.
Try creating the table again and don't click the refresh button without first saving/applying your changes with the up arrow icon.
Does SQLite allow using UUID as a primary key? Sorry for the question, but I’ve been using this format in my project and, when saving, Wappler changes it to string. Maybe I’m using something that isn’t supported.
Sorry, no sqlite does not have inbuilt support for UUIDs
Also,due to the Wappler use of knex() to manage database access, mysql/maria db does not return the uuid of a new record after an insert action which is extremely problematic
As Brian (@Hyperbytes) has stated, SQLite doesn’t natively support UUIDs as a dedicated type, so Wappler (via Knex) treats them as strings, typically TEXT or BLOB. You can use a UUID as a primary key, but it’s worth considering the trade-offs:
Performance: UUIDs are larger than integers (128 bits vs 32/64 bits), which can slow down indexing, joins, and lookups—especially in large datasets.
Join Complexity: UUIDs make foreign key joins bulkier and less cache-friendly, which can impact query speed.
Storage Overhead: UUIDs stored as text take up more space (36 characters vs 4–8 bytes for integers).
If you’re using UUIDs for global uniqueness (e.g., syncing across systems), a hybrid approach might serve you better:
Use an INTEGER PRIMARY KEY (which maps to SQLite’s internal rowid) for fast joins and indexing.
Add a secondary UUID TEXT UNIQUE column for external references or syncing.
This gives you the best of both worlds: performance and global uniqueness.
