More granular table traits#4775
Conversation
There was a problem hiding this comment.
This is the main change to functionality. I wanted to have access to specific traits so in bevy_stdb I can go from:
Before/after
fn bind_insert<TRow, TTable>(world: &World, table: &TTable)
where
TRow: Send + Sync + Clone + InModule + 'static,
RowEvent<TRow>: Send + Sync,
- TTable: Table<
+ TTable: WithInsert<
Row = TRow,
EventContext = <<TRow as InModule>::Module as SpacetimeModule>::EventContext,
>,
TTable::EventContext: AbstractEventContext<Event = RowEvent<TRow>>,
{
let sender = channel_sender::<InsertMessage<TRow>>(world);
table.on_insert(move |ctx, row| {
let _ = sender.send(InsertMessage {
event: ctx.event().clone(),
row: row.clone(),
});
});
}There was a problem hiding this comment.
Trait changes mean we need updated codegen too (breaking).
|
|
||
| impl<'ctx> __sdk::EventTable for {table_handle}<'ctx> {{}} |
There was a problem hiding this comment.
Do we need these empty impls? Maybe now Table can just be removed entirely?
| /// | ||
| /// For persistent (non-event) tables only. See [`EventTable`] for transient event tables. | ||
| pub trait Table { | ||
| pub trait TableLike { |
There was a problem hiding this comment.
Maybe this could have a better name? Its meant to be the common things all tables have.
|
I see the Discord thread, but could you expand on what the motivation for this is in the PR description? An example of what this enables would be helpful. |
Updated 😄 |
Description of Changes
This looks like a large diff but the real changes are just
sdks/rust/src/lib.rsfor traits andcrates/codegen/src/rust.rsfor the new codegen.Refactored the Rust SDK table trait surface into composable capabilities and updated Rust codegen to match. Discord thread
Motivation
The granular traits are a useful type-system cleanup on their own, but the main motivation is to let downstream integration crates like bevy_stdb express callback capabilities more directly instead of routing them through broader semantic categories.
For example,
bevy_stdbmay want to support bindings like “forward only inserts from this subscribed view as Bevy messages” for a relation that is not semantically anEventTable. Today this can still be made to work with broader abstractions, so this is not primarily about enabling new runtime behavior. The value is mostly at compile time: more precise trait bounds, clearer downstream APIs, and better guarantees that a binding only requires the capabilities it actually uses.Concretely, this makes it easier for integration crates to model things like insert-only or delete-only bindings for ordinary tables or views without conflating those behaviors with
EventTablesemantics.Example:
Summary
TableLiketrait for common table handle functionality:RowEventContextcountiterWithInsertWithDeleteWithUpdateTable: TableLike + WithInsert + WithDeleteTableWithPrimaryKey: Table + WithUpdateEventTable: TableLike + WithInsertTableLikeWithInsertWithDeleteWithUpdateTable,TableWithPrimaryKey, andEventTablespacetimedb_sdk::__codegenso generated bindings can compile correctlyAPI and ABI breaking changes
Yes — this is an API-breaking change in the Rust SDK trait hierarchy.
Notable changes:
WithInsertWithDeleteWithUpdateTable/EventTableimpl blockExpected complexity level and risk
3/5
This is a moderate refactor because it changes the Rust SDK trait model, affects Rust code generation, and requires the generated binding surface and SDK re-export surface to stay in sync.
Main interaction points:
sdks/rust/src/table.rssdks/rust/src/lib.rscrates/codegen/src/rust.rsTesting
cargo check --manifest-path /Users/onx2/Documents/projects/SpacetimeDB/sdks/rust/Cargo.tomlcargo test --manifest-path /Users/onx2/Documents/projects/SpacetimeDB/Cargo.toml -p spacetimedb-codegen test_codegen_rust