Feat/composite primary keys

[fire]

Proof of concept.

Coded by AI.

Let me know if you want me to work on it more and what parts.

Fixes: #103

[jessestimpson]

Thanks for the PR. I will take a closer look and get back to you soon.

[jessestimpson]

@fire Thanks again for the PR. I'm interested in hearing what your benchmarks reveal if you're willing to share the info someday.

This is a good feature for the project. My review is kinda long, and I want to respect your time: I would be willing to pick this up where you left off if you're unable to devote more time to it.

---

There are several spots in EctoFDB that are still assuming a single field pk. At minimum for this PR we should raise an Unsupported exception to prevent corruption or harmful query results, and we can knock them out in future changes. Let me know what you think.

High priority

1. If a Schema has both a composite primary key and a migration that adds an index, the primary key as written to the index value is malformed, resulting in a corrupted index and queries that return wrong data. Suggestion: For now, raise an Unsupported exception in Default.create/6 that would block the migration from creating the index in the first place. A future enhancement could add index support.

put(1, 1, "n1"); put(1, 2, "n2")
from(d in District, where: d.d_name == ^"n1") |> TestRepo.all(prefix: t)
# ** (MatchError) no match of right hand side value: [%DecodedKV{...}, ...]

2. The order_by feature in EctoFDB. This feature is sensitive because we require a query to map directly to a single GetRange. If a query orders by primary key, we can fulfill it, but composite primary keys make this a bit more complicated. In theory we could order by any prefix-list of the composite primary key, of course up to and including the full list. Suggestion: raise another Unsupported exception when attempting to order_by on a field that is part of a composite primary key.

put(1,5); put(2,1); put(1,9)
from(d in District, order_by: [desc: d.d_id], limit: 1) |> TestRepo.all(prefix: t)
# => [{2, 1}]   expected [{1, 9}]

Medium

1. There are lines like this one in TxInsert.do_set/4 that still assume a single field. I think more tests would help to root these out.

    %DecodedKV{data_object: data_object = [{pk_field, pk} | _]} = new_kv

2. Composite pk interactions with Versionstamp and partition_by

3. I believe Repo.assign_ready might fail, but haven't confirmed yet.

Low

1. I think get_pk_field! (singular) can be deleted in favor of the more general get_pk_fields!.
2. Fields.composite_pk?/1 is unused. Although, perhaps it becomes useful for the logic involved in raising Unsupported exceptions.
3. Would be useful at this time to standardize code on Fields.to_front. In particular, there is old code that uses Keyword.delete in TxInsert that can go away.
4. Changelog, docs

[fire]

Feel free to pick up where I left off.

I am low on cashflow. So I am unable to devote more time to composite primary keys.

For my social vr game, I switched to a design where SQLite writes pages to Foundationdb.

Similar to https://rivet.dev/docs/actors/sqlite/ and https://su3.io/posts/mvsqlite in design.

https://github.com/v-sekai-multiplayer-fabric/weft/blob/main/docs/benchmarks.md (Stale benchmarks)

[fire]

we should raise an Unsupported exception t

In Elixir I'm always confused which one is correct many apis provide exception! style and also return {:error, tuple}.

One can always convert error tuple to exception style but the reverse is not easy.

[jessestimpson]

we should raise an Unsupported exception t

In Elixir I'm always confused which one is correct many apis provide exception! style and also return {:error, tuple}.

One can always convert error tuple to exception style but the reverse is not easy.

In the case of an ecto adapter, the API surface is mostly defined by Ecto.Repo so our hand is forced into using exceptions to communicate with the developer. The UnsupportedException exists because EctoFDB takes an opinionated stance about what types of queries are possible, because unlike most RDBMS it lacks a sophisticated query planner.

For other elixir projects I do prefer error tuples.

[jessestimpson]

I've merged your work into a staging branch. If you have any more additions, please land them there. In the meantime, I'll work through the other items so this can land on main.