[ADP-2565] Implement Table database schema type and basic SQL operations

[HeinrichApfelmus]

This pull request

• Implements a type Table that represents the schema of a table in a database.
• Implements a basic set of database operations on top sqlite-simple that work with this Table schema type. A demonstration can be found in Demo.Database.

Comments

• The SqlM monad, more precisely the runSqlM function, currently makes no attempt at handling exceptions or concurrency correctly. It doesn't look like this will turn out to be a good idea, I will fix this in a future pull request.
• I have skipped extensive property testing for now, as I want to stabilize the API first. The module Demo.Database provides a basic functionality check.

Issue Number

ADP-2565

[Anviking]

👌 looks neat

[Anviking]

I was wondering why you didn't have a single getColumns :: ... -> [(ColumnName, SqlType)] to ensure the right column is paired with the right type (e.g. that one list hasn't been reversed) I suspect you did this to keep Database.Table.Schema separate from any notion of SQL/Sqlite though.

[HeinrichApfelmus]

suspect you did this to keep Database.Table.Schema separate from any notion of SQL/Sqlite though.

Indeed.

I also would have liked the module Database.Table.SQL.Column to not depend on specific types from sqlite-simple, because the SQL language is, in principle, independent of any particular backend such as SQLite. But that would have meant duplicating the types, and I left it at this.

[Anviking]

I'm guessing this is the faster version of

cardano-wallet/lib/delta-table/src/Database/Table/Schema.hs

Lines 80 to 85 in 7cf4008

	-- FIXME? O(n^2) when getting names
	instance (IsTable t, KnownSymbol name) => IsTable (t :. Col name a) where
	getTableName _ = getTableName (Proxy :: Proxy t)
	getColNames _ =
	getColNames (Proxy :: Proxy t)
	++ [T.pack $ symbolVal (Proxy :: Proxy name)]

why not use the same approach in both cases?

[HeinrichApfelmus]

why not use the same approach in both cases?

Laziness on my part — it was quick enough to write. 😂 I'll use Data.Sequence for both.

[Anviking]

I guess we'll likely need to support both non-int and multi-column primary keys though?

cardano-wallet/lib/wallet/src/Cardano/Pool/DB/Sqlite/TH.hs

Line 135 in 7cf4008

Primary poolOwnerPoolId poolOwnerSlot poolOwnerSlotInternalIndex poolOwnerOwner poolOwnerIndex

... which would make it more like

type TablePerson =
    Table "person"
        :. Col "name" Text
        :. Col "birthyear" Int
        :. PrimaryKey ["name", "birthyear"]

? (modulo exact syntax of :. PrimaryKey )

Also foreign keys...

[HeinrichApfelmus]

I guess we'll likely need to support both non-int and multi-column primary keys though?

After some thinking, I have come to the conclusion that I don't want to support primary keys — the simplest for semantics for Table is the semantics where the rows are not required to satisfy additional uniqueness constraints. 🤓

These constraints provide only marginal value for us anyway — when writing code that writes to the table, we have to ensure uniqueness as an invariant, and the only thing that the SQLite uniques constraint gives us is a dynamic error message when this invariant is violated — meh.

Foreign keys are relevant for the interaction of multiple tables — which is also out of scope for Table at the moment.

The Primary type was a small concession to the possibility of having uniqueness constraint in SQLite — but I think that we are better off removing it.