Add primary key support for procedural views to rust and ts modules

[joshua-spacetime]

Description of Changes

Adds support for primary keys to procedural views in rust and typescript modules. Now clients can receive update events when subscribed to such views.

#[spacetimedb::view(accessor = my_players, public, primary_key = id)]
pub fn my_players(ctx: &spacetimedb::ViewContext) -> Vec<Player> {
    ctx.db.players().owner().filter(ctx.sender()).collect()
}

const Player = t.row('Player', {
  id: t.u64().primaryKey(),
  owner: t.identity().index('btree'),
  name: t.string(),
});

export const my_players = spacetimedb.view(
  { public: true },
  t.array(players.rowType),
  ctx => Array.from(ctx.db.players.owner.filter(ctx.sender))
);

In rust, a view's primary key is declared within the #[view] macro, whereas in typescript it is declared at the column/row level as it is for tables. I could have made it a view level attribute for typescript as well, but since primary keys are already row-level attributes in typescript, I just kept that as is.

Note, care must be taken to ensure that the view never returns duplicate primary keys, or else it will fail which will currently result in the transaction that triggered the view refresh to be rolled back. Better error handling for this exact scenario will be added in a separate follow up patch.

Alternative Considered: #[primary_key] attribute on SpacetimeTypes in Rust

This would be equivalent to what we do in typescript.

API and ABI breaking changes

None, although adding a primary key to an existing view will require a client update.

Expected complexity level and risk

3

Testing

Compile-time failure scenarios:

• Primary key on non-existent column
• Primary key doesn't reference custom accessor name (rust)
• Multiple primary key columns specified (typescript)
• Primary keys must be FilterableValues

SDK tests (rust sdk, rust and ts modules):

• OnUpdate
• OnUpdate is sender-scoped
• Can join on primary key columns

Smoketests:

• Modifying primary key columns breaks clients (auto-migrations)

[gefjon]

I have not carefully reviewed the tests or the typescript code, but the Rust stuff looks good to me. The tests are at least at a glance reasonable. I don't love the difference between the Rust and TypeScript designs, but I can live with it, I suppose. Do we have a ticket for the C# and C++ implementations? If not, could you make one?

[JasonAtClockwork]

It looks good but it does seem there is a missing check on the TypeScript side. For Rust you have the requirement that primary keys for views must be a FilterableValue but on TypeScript that isn't checked.

For example, this will fail in Rust:

#[derive(SpacetimeType)]
pub struct BadViewRow {
    pub identity: TimeDuration,
    pub name: String,
}

#[view(accessor = bad_time_duration_pk, public, primary_key = identity)]
pub fn bad_time_duration_pk(_: &ViewContext) -> Vec<BadViewRow> {
    vec![]
}

However in TypeScript this will compile:

const BadViewRow = t.row('BadViewRow', {
  identity: t.timeDuration().primaryKey(),
  name: t.string(),
});

const spacetimedb = schema({});
export default spacetimedb;

export const bad_time_duration_pk = spacetimedb.view(
  { public: true },
  t.array(BadViewRow),
  () => []
);

[joshua-spacetime]

For Rust you have the requirement that primary keys for views must be a FilterableValue but on TypeScript that isn't checked.

Note, this is a pre-existing issue. It applies to tables as well. I'll update this in a followup patch since it's not a regression.