Feature Requests

This has been asked for several times but most recently in discord: https://discord.com/channels/1037340874172014652/1352309930010480791/1352309991088062569 We need a way to have a column in one table reference a column in another table, something like: ```rust #[spacetimedb(table, name = "my_table", )] pub struct MyTable { #[primary_key] #[auto_inc] pub id: u64, // ... } #[spacetimedb(table, name = "another_table")] pub struct AnotherTable { // WARNING: This is pseudocode and does not actually work. #[foreign_key(MyTable)] pub id: u64, // ... } ``` The user I referenced above has this specific case where they have a `Vec<u64>` which each one of those `u64`s references a key in another table. So it's more like something like this: ```rust #[spacetimedb(table, name = "player_inventory")] pub struct PlayerInventory { #[foreign_key(Item), cascade_delete=false] pub items: Vec<u64> } #[spacetimedb(table, name = "item")] pub struct Item { #[primary_key] #[auto_inc] pub id: u64, pub name: String, // ... } ```

Is it supported already and im doing something wrong? ```rust #[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize, SpacetimeType)] pub struct AccountId(pub u64); #[table(name = account)] pub struct Account { #[primary_key] #[auto_inc] pub id: AccountId, pub created_at: Timestamp, } ``` ``` 1. proc-macro derive panicked message: called `Option::unwrap()` on a `None` value 2. proc-macro panicked: called `Option::unwrap()` on a `None` value the trait bound `for<'de> schema::account::AccountId: spacetimedb::Deserialize<'de>` is not satisfied. the column type `schema::account::AccountId` does not implement `SpacetimeType` table column types all must implement `SpacetimeType` if you own the type, try adding `#[derive(SpacetimeType)]` to its definition the following other types implement trait `spacetimedb::SpacetimeType`: ```

We already have btree and hash indicies but the `hash` index route for mutli column indices is not ideal to enfore the uniqueness invariant in a convenient way. This would also be immensily usefull for procedural view primary keys because you could actually determine a pk for a subset of your data :> _Requested by [@kistz](https://spacetimedb.com/@kistz) via the SpacetimeDB site._

I would like the ability to declare a table as a disk table, where disk tables are cheaper, with higher limits, but may have higher access latency: ``` #[table(accessor = foobar, storage = disk)] struct Foobar { id: u64 } ```

## Summary While Maincloud is not technically on a bleeding edge or nightly release cycle, the latest version is deployed immediately after a new SpacetimeDB release. Your only option to not upgrade to latest is to use Standalone or lock in an Enterprise deal for a private node. Each of these have issues: - Standalone -> Free, but doesn't scale - Enterprise -> Potentially costly, and overkill for most The logical conclusion for a vast majority of users is to use shared hosting, a-la Maincloud. It even comes with `SLA / Uptime Guarantees` if you're a Pro subscriber. ## The Issue I have no doubt that a lot of effort goes into this, but deploying new SpacetimeDB versions to Maincloud without any issue or bugs is a tall order- in fact, it's an impossible order. The new version is being deployed to thousands of modules, all on various runtime versions, and some functionality will be tested live for the very first time in unexpected ways. We can have 1,000 different smoke tests, but they will never handle all of the edge-cases. This has, and will continue to lead to disruptions to Maincloud customers. If your app or game has paying customers, this type of disruption is not acceptable. Playing devils advocate- some would even argue that these types of disruptions indicate that Maincloud is not a production-ready environment. ## Proposal Similar to [#5204](https://github.com/clockworklabs/SpacetimeDB/issues/5204) and its related [feature request](<https://spacetimedb.com/features/requests/38>) I would love to see a LTS Maincloud instance that is fixed to a specific stable build. `spacetime publish <module_name> --lts` This would prevent new Maincloud version deploys (and bugs) from disrupting production applications deployed on LTS Maincloud, giving potential start-ups and businesses peace of mind knowing their backend infra is stable. ## Challenges I acknowledge this comes with many challenges, so I am looking for feedback and replies in the github thread: - Does current maincloud transition to LTS or Latest? - Maincloud will need module migration tool to go from server to server - Can you only migrate your module from LTS to Latest and not the other way around? - At what interval is the LTS version updated? What type of key milestones indicate a version bump? - What type of deploy/patches are allowed on LTS? Bugfixes only? What about QoL? - What should be the default Maincloud publish functionality, LTS or Latest? Happy to hear your thoughts. Let's have a discussion.

SpacetimeDB could be really useful for Minecraft Plugin developers to code against that type of DB. Minecraft servers like Hypixel, Wynncraft have their own infrastructures that took serval years to build - including data synchronization, sharding, synchronized players and more. Basically a API that you could implement into Maven or Gradle and interact with SpacetimeDB.

it would be nice to be able to define parameters for views to not need to use tables to define what data the client wants.

it would be really useful to have an index type for pagination. my idea is `#[index(page(page_size))` (idk rust enough if that is valid/good syntax for this) that is accessed with `ctx.db.table.column.page(nr)` and returns the subset of rows defined by the page_size that's sorted by the column it was used on. this would simplify and optimise leaderboards, Auction pages, any form of listings and so on a lot. once view parameters are out, it would be possible to make a view that takes the page nr as parameter and then just get the subset without having to manually sort and subset the data within the view. as for the client updates, the client could just insert sort the new and deleted rows, so there is no need to change bsatn or the WS protocol for that

I would like to be able to call a reducer on another database from within my database. I want the reducer to be able to return the result, and I would like it to do so atomically: Receiver (payments) — a plain reducer that returns a value. ctx.sender is the calling database's identity. ```rs #[spacetimedb::reducer] fn charge(ctx: &ReducerContext, customer: Identity, amount: u64) -> Result<u64, String> { let mut acct = ctx.db.accounts().customer().find(customer).ok_or("no account")?; if acct.balance < amount { return Err("insufficient funds".into()); } // aborts the whole tx acct.balance -= amount; let new_balance = acct.balance; ctx.db.accounts().customer().update(acct); Ok(new_balance) } ``` Caller (orders) — the call is inline; the local insert and the remote charge commit together or both roll back. ```rs use payments; #[spacetimedb::reducer] fn place_order(ctx: &ReducerContext, item_id: u64, price: u64) -> Result<(), String> { let payment_db = ctx.db.config().single().payment_db; // a stored payments::Identity // Sync cross-database call (Level 7, 2PC). `?` aborts the whole distributed tx on Err. let new_balance = payments::Identity(payment_db).reducers.charge(ctx.sender, price)?; ctx.db.orders().insert(Order { id: 0, customer: ctx.sender, item_id, price, balance_after: new_balance }); Ok(()) } ```

I would like to be able to send messages from one database to another via an outbox table.

it would be nice to be able to write subscriptions that subscribe to multiple tables at once with conditions that link them. something like: ```sql "SELECT * FROM auction_listing as AL, user_name as UN, item_lookup as IL WHERE AL.cathegory = 'Weapon' LINK AL.entity_id = UN.entity_id, AL.item_id = IL.item_id" ``` and it is like writing 3+ separate subscriptions and returns the rows of the 3 tables where the link and where condition matches. the problem currently is that it is a pain to get related data from multiple tables without opening potentially hundreds to thousands of subcriptions per client.

Right now it is reasonably expensive to load in physics, terrain, or nav data during a "tick" which is the hottest path. Ideally we have some first-class support for a cheap read-only table that can be initialized at startup. Right now there is the potential to use a `const` or `static` but with caveats so having the team support this pattern out of the box would be really valuable. For example, I have navmesh grid data that is ~8mb. I need to load in ~200 bytes * 9 (for the chunks surround) per moving entity. So if I have 100 players and maybe 1000 monsters running around thats 1,100*200*9 potentially bytes read every ~100ms when I never need to edit this data. I can simply add this data into a const and bundle it with the module but it doesn't feel like "the spacetimedb way" of doing things. If something is 100% read only I'd like a way to read that data for close to free instead of the charge at the same rate as hot data.

# Improved SpacetimeAuth Web UX ## Summary I’d like to request improvements to the SpacetimeAuth web login experience, especially for apps using third-party providers like Google and Discord. ## Issues ### 1. Extra authorization step The current identity-provider flow appears to require these steps: 1) Click login button on app 2) Click “Login with Google/Discord/etc.” 3) Click authorize with the provider 4) Click “Authorize Application” That fourth step is confusing for new users because they feel they already authorized the login provider. Ideally, third-party auth would only require selecting the provider and approving the provider login. If the extra step is required for technical reasons, the page should more clearly explain what is being authorized and why. ### 2. Login screen polish Play testers said the SpacetimeAuth login page looked somewhat “sketchy,” especially when only Google and Discord providers are available and email login is not enabled. A few CSS/layout improvements would help it feel more trustworthy and consistent with the polish of the main SpacetimeDB website. ### 3. Embedded login option It would be super helpful to support embedding the provider selection directly inside an app, similar to Firebase Auth, instead of requiring a redirect away from the page. ### 4. Role management Role management would still be useful, but it is lower priority for me because I already implemented a custom solution. ## Impact These changes would reduce login friction and improve trust for users trying apps built on SpacetimeDB, and prevent losing new players in the onboarding process. _Requested by [@doodlechaos](https://spacetimedb.com/@doodlechaos) via the SpacetimeDB site._

Something like this: ``` // Pseudocode func upsert(ctx, primary_key_value, value): if ctx.primary_key_column.try_find(primary_key_value): // Row with a matching primary key column exists ctx.primary_key_column.delete(primary_key_value) ctx.primary_key_column.insert(primary_key_value, value) ``` In order to `upsert` on a column it needs to have a unique constraint on it.

This is somewhat related to #4031, but I would like full type support for enums, mainly named field variants ```rs enum Birthday { Custom(String), // ? currently unsupported Date { day: u8, month: u8, year: Option<u16> } } ``` as well as tuple variants ```rs enum Birthday { Date(u8, u8, Option<u16>), ... } ``` both currently error with `must be a unit variant or a newtype variant` You *can* get around this by creating a struct and wrapping it as a newtype variant, but for types that will only ever be used as a single enum variant, that's not ideal. In my testing manually implementing the derive macro, sats seems to support named field variants just fine, and with only that change you can deploy to maincloud without issue, reads and writes all work, only the module codegen step currently fails. I haven't tested tuple variants, as I don't personally need them, they're just listed here to complete the type support.