GRDB 3.2 released

Related Projects GRDB
1

Hello Swift community,

GRDB 3.2 is out, a convenience release that helps you nuking your SQLite database during the development phase, when the database schema evolves a lot: release notes.

On top of that, GRDBObjc has been updated as well. GRDBObjc makes it easy to mix and match Objective-C and Swift in your app. When the new Swift code uses GRDB, the legacy Objective-C code keeps on using the database through a FMDB-compatible api.

Happy GRDB!

1 Like
2

Just an idle thought, but have you considered somehow making it harder to accidentally ship with eraseDatabaseOnSchemaChange on? I'm not sure what this would look like exactly, but my first thought is roughly something like “it only works in debug mode unless you pass some compilation flag”.

3

Hello @jawbroken,

There is a possibility that some app want to be distributed with eraseDatabaseOnSchemaChange on. This is a door that has to remain open.

Now the flag is intended to nuke the db when the schema changes. Its current implementation has no false negatives (it spots all schema changes), but it may still have false positives (it may spot a change when there isn't). Such false positive may happen when the schema comparison is performed against a database that was created with a former version of SQLite, or a former version of GRDB. I didn't spend time trying to address those false positives yet (I don't even know for sure if they do exist for real, and/or if they can reliably be avoided). I have to look closely at the source code for sqldiff.exe: Database Difference Utility.

I first and foremost want to avoid misleading users, and losing their data. I also want to avoid the many issues attached to the inspiration for this flag: Realm's deleteRealmIfMigrationNeeded.

That's why the documentation is extra careful, insists on the flag danger, and suggests hiding it behind #if DEBUG.

And I'm happy that you ask this question, because it proves that the doc has done its job: you had first thoughts and expectations, and those were modified.

Enough rationale. Did you have an alternative api in mind?

4

Yeah, I noted that from use case 2 in the documentation, and I do think the documentation is very clear about the danger. I was only wondering in my previous post if it was possible to have some mechanism whereby a developer who wanted the behaviour in release builds would have to more explicitly opt in. I'm not sure there's a public API for detecting release builds though, just _isDebugAssertConfiguration() and friends. And now that I think about it, it's more complicated than that because your library can be compiled separately, so there's probably no great solution here besides developer care.

5

I agree. Tools like Carthage can only build release libraries.

Now, on the fun side, I've seen on the internet code like below:

var debugMode = false
assert({ debugMode = true; return true }())

if debugMode {
    ...
} else {
    ...
}

And we also have https://forums.swift.org/t/draft-introducing-a-debug-build-configuration-test/1794:

#if /* assertions can fire */
    ...
#else
    ...
#endif