Database seeds

[jcavar]

I haven't encountered any advice for or against use of database seeds in GRDB.

The main reasons why I am considering using seeds is:

• It makes it easy to couple database seed with current version of model objects. E.g. if we have V1 DB something like:

struct UserDB: PersistableRecord {
    let id: String
}

and in V2 we have:

struct UserDB: PersistableRecord {
    let id: String
    let name: String
}

It would not be safe to use in migration code.

• The other reason is that for new installations, we skip all the migrations before since we have seed DB on latest version

This is to some extend covered in:

https://swiftpackageindex.com/groue/grdb.swift/v6.7.0/documentation/grdb/singlerowtables

but seed data can contain multi row entries in some cases.

I am interested what are general guidelines about this topic?

[groue]

The other reason is that for new installations, we skip all the migrations before since we have seed DB on latest version

From my personal point of view (strictly personal), skipping migrations makes the app more complex, and I'd rather avoiding this.

If the database is seeded in version N, then it becomes more difficult to guarantee database invariants for users who install version N, and for users who upgrade to version N. It's more code, more opportunities for bugs, (hopefully) more tests. And complexity increases, unbounded, when the number of seeded versions increases.

On the contrary, when the database schema walks along a strictly linear path of migrations, for all versions, then it's easier to control the database content:

func prepareDatabaseForApplicationUse() {
    try dbMigrator.migrate(dbQueue)
    // Complexity, if any, is only there:
    try make_sure_the_database_contains_the_data_required_for_the_current_version(dbQueue)
}

Of course, there are some applications who need to optimize database setup. Migrations may become slow, or impractical to use is some way. In this case, maybe it can be useful to skip migrations and perform some dedicated setup. As with all optimizations, one needs a good reason to perform it, since this makes the app less regular and more complex.

Again, this is only a personal opinion. Your app may have specific needs that I'm not aware of.