Nicole Tietz-Sokolskaya 65ad20d197 Switch DB layer to Diesel from SeaORM and Fjall (#2 )

Refactors Pique to use Diesel for the backing database layer instead of the previous choices of SeaORM and Fjall (with a custom DB on top of the KV store). This choice was made to speed up development. I found SeaORM much more challenging to discover things in than Diesel, and with Fjall I was getting mired in building things that already exist. This is a migration to a boring choice, and that's the right decision for this moment in time.

Among other things, the diff stats wind up being `47 files changed, 926 insertions(+), 950 deletions(-)` when you exclude lockfile changes and markdown changes. This validates that the code is not significantly more or less verbose, but is simply structured differently. So we're not giving anything up in brevity.

I decided to structure query calls into their own submodules, called `q` (short for `query`). I shortened the names to make it easier to type and make lines shorter, which may be a controversial take, but I think that it will wind up being worth it and will be easy to get used to.

I also renamed `Context` to `Provider`, because I think `Context` implies things like cancellation, while `Provider` implies giving access to resources, which is more precisely what's going on here.

Reviewed-on: #2

2024-06-02 18:37:15 +00:00

1.4 KiB

Raw Blame History

4. UUIDs for primary keys

Date: 2024-05-31

Status

Proposed

Context

We need primary keys in our database.

I've used integers and UUIDs for this in different contexts. Ultimately, we have to decide on which one to use.

Decision

We're going to use UUIDs for our primary keys.

The primary motivation here is that it will give us the ability to generate IDs before inserting records, and it lets us expose the IDs more easily. Instead of either leaking information (count of users, etc.) or having a secondary mapping for URLs, we can easily use the ID in a URL to map to a record for lookup.

Consequences

There are some drawbacks:

We lose some type safety, becasue SQLite only supports text/blob types and it's been a blocker trying to implement custom sql types in Diesel, so this is going to be done by converting to strings and operating on these IDs as strings.
They take up more space

However, we get these benefits:

We can expose primary keys without leaking information. This makes it so we do not need secondary IDs (and associated indexes) for looking up specific records and putting them in URLs, where if we used integers we'd need that or we would have to accept exposing the number of records we have.
IDs are unique across tables, so they should give us the ability to find a particular row even if we don't know the table. This also means we could link events, like edit events, to any table via UUID.

1.4 KiB Raw Blame History