Nuking db during development

[bellebethcooper]

Hello,

Sorry for another question so soon! I've scoured the docs re: migrations and haven't been able to find the answer I'm looking for. I'm developing an app that's a client for a web app, so I'm using GRDB to persist the user's data locally after requesting it from the server. While I'm in the development phase, there are many times I want to force the app to request server-side data in order to test changes I'm making, and I'm struggling to figure out how to do this.

When using Realm previously there was a way to skip doing any migrations and just nuke everything in the db. This is essentially what I want: a temporary way to make each new load of the app have an empty database until I'm ready to send it out to users and start using migrations.

Is something like this possible with GRDB?

Thanks a lot!

[groue]

Hello again @bellebethcooper. GRDB won't nuke your database automatically :-)

My personal practice is to check a RESET environment variable in the scheme editor (in the "Run options" tab if I recall correctly). The app checks for the presence of this environment variable, and erases the database if it is set. When the database schema is ready, I uncheck this environnement variable.

It is easier to erase the database when it is stored inside its dedicated repository: you juste have to remove the directory, and all database files are removed altogether (main db file, -wal and -shm files, other temporary SQLite files...)

[groue]

I didn't know this need was common. Do you think we should provide an API for that? How does Realm do?

[bellebethcooper]

@groue That sounds like a great approach. I'll give it a go; thanks!

I don't know how common this is, but for me there are two reasons to use it. One is during initial development, when my schema can change a lot (especially if the API I'm working with is being developed at the same time). The other is in a case like the bookmarking client I'm working on, where the app is a mobile client for a web service, and the server acts as the single source of truth, so I'm really just using GRDB (and previously Realm) for local caching to speed up loading for the user, but I don't really need to worry about migrations and so on, since I can just nuke the local database and load fresh data from the server if I need to.

In Realm, it's really simple to set this up. There's a Bool used in the Realm config called deleteRealmIfMigrationNeeded. Docs here.

Thanks again for the quick response and for sharing your approach to this!

[groue]

Thanks for distinguishing those two use cases, @bellebethcooper, this is very interesting. I now miss the deleteRealmIfMigrationNeeded flag myself :-)

I don't quite know how it could be implemented... One technique could be to run the migrator on an empty temporary database, and nuke the original database if its schema is different?

[bellebethcooper]

No problem! I'm using the approach you mentioned above during development currently, and that's working well for me right now. But your idea of using a temporary database sounds like it would work, too. Thanks for your help in figuring this out!

[groue]

All right @bellebethcooper! The idea has been added to the to-do list 👍

[bellebethcooper]

Thanks very much!