clockworklabs / clockworklabs/SpacetimeDB

Consider adding `#[must_use]` to `#[table]` rows in Rust modules

Open
#2,261 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
25.2k
Forks
1.1k
Avg merge
2d 7h
Merged PRs (30d)
46

Description

Upsides

This would catch anywhere the user updates a row struct but forgets to commit it. This is likely to be particularly helpful to new users who don't understand the data model, but it would help experienced users as well.

E.g.

fn update_username(ctx: &ReducerContext, id: UID, name: String) {
   let mut user = ctx.db.user().id().find(id);
   user.name = name;
   // whoops! this does nothing!!
}

Downsides

You have to explicitly discard rows you don't need, e.g.

fn update_username(ctx: &ReducerContext, id: UID, name: String) {
   let mut user = ctx.db.user().id().find(id);
   user.name = name;
   // now you need this `let _ =` to avoid a warning, because the `update` method returns the updated row.
   let _ = ctx.db.user().id().update(user);
}

This makes using Row structs as plain-old-structs slightly less convenient. I still think it's worth it.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating how #[table] row types are defined or generated in Rust modules and how row updates are represented. Assess whether #[must_use] can cover forgotten row commits without making intentional discarded results impractical. Done means the behavior is implemented consistently and the examples in the issue’s update and explicit-discard cases are covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
databases
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.