Demo apps access the database via a PlayerRepository package

[groue]

The demo apps access the database via a new, shared, PlayerRepository package.

In a way, this makes the demo apps less simple 😬

But it also demonstrates some useful practices for setting up such a package. Some reasons for satisfaction:

• The PlayerRepository package does not hide GRDB.

  Not hiding GRDB is not a design flaw, because it is illusory to pretend that such a package can easily abstract over its database implementation. BlackBird, Core Data, GRDB, Realm, or SQLite.swift have fundamental differences in usage and, more importantly, runtime behavior: very few apps and teams have the need, opportunity, time and skills, to design and implement a correct abstraction layer over two of those libraries, let alone more than two.

  Once GRDB is exposed, applications can easily create their on-disk database at the location of their choice. Tests and previews can use in-memory databases, empty or populated with interesting data. That's handy.

  Applications are not allowed to perform random writes - that's how the package can guarantee database integrity. That's important.

  Read-only accesses are totally free, so that application components can perform the database requests they need, isolated from other app components. This prevents the repository package from being polluted with myriads of ad-hoc requests that are never reused. This also helps avoiding including in the package database accesses that are insufficiently vetted, and not ready for sharing (Rule of Three, YAGNI).

• The PlayerRepository package handles database configuration while allowing applications to customize it if needed. This is an opportunity to demonstrates how to enable SQL logging with OSLog, as well as verbose logging in debug builds only (so that release builds don't log sensitive information), at the package level.