Feature Requests

I would SpacetimeDB to support LLM vector indexing and search

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.

it would be nice to support f32, f64 in index(btree) as it is the base for vectors and basically used everywhere in games. i understand that there will always be a EPSILON uncertainty but i can live with that. the advantage of not having to store the position as i32, i64 and convert + div 1000 to get the position is more than worth the edge cases on the edge (pun intended). i would even be fine if the index floats just get rounded to 0.01 precision and converted to i32/i64 (with * 100) to act as easy to compare value.

it would be nice to have long time metrics of the module like the ccu curve over the last month and the corresponding energy cost data. currently it is near impossible to tell what happened to the module if we don't have it actively running while something bad happens and even for the few metrics that are loading a bit of the past, it isn't showing enough of the past to tell what happened a day later. again this would be a lot easier if the metrics would be stored in a st_metrics (event) table and read from the clog for the dashboard to get the data for a specified time (like the last month in x steps per hour accumulated and/or not)

the metrics pages are nice and useful but it isn't clear what the graphs are actually showing. some of them are showing the accumulated values per minute, some per 30 or 15 seconds and some have their time scale all over the place depending how the graph loaded. for some i don't even know what to do with the value like the table storage being in mb but being calculated as GB-seconds in the energy usage. i have one reducer that runs every 2 seconds and the graph shows it as 1.6 to 2 TPS with a time scale step of 30 seconds. is that an accumulated value too? how does it get to 2TPS? at best this is VERY misleading. besides that, why aren't the metrics stored in a st_metrics (event) table that the dashboard can just load from the clog or at least get as subcription. this also would allow the standalone version to have metrics too.

we need a way to disconnect clients from the server side. ideally both through, `ctx.disconnect_identity(identity: Identity)` and ctx.disconnect_connection_id(connection_id: ConnectionId). this is required to be able to build ban systems as custom clients can just not react to any "server says disconnect" setups. a timeout system also requires this but can be worked around with the "server says disconnect" setups but it isn't nice and can be ignored on the client side as mentioned. the disconnect_connection_id alternative is needed when multiple clients can connect to the same identity at the same time and we don't want to disconnect all connections or something like that. (it's mostly to have the option) doing a direct ctx.disconnect_sender() is not as useful as it doesn't work with scheduled reducers/procedures.

currently the bandwidth is one of the more expensive costs of stdb. part of that is that deleted rows are send as full row even if the PK alone would be enough for the client. for high update rate tables, this means it is sending almost double the data than it should be. for row updates, it wouldn't even need the delete row at all as the client can just check if it has the pk in local cache and generate the update callback with just the new insert row. so in short: - deleted rows with PK could just be the PK - updated rows with PK could just be the new insert row and no deleted row. - rows without PK would still need to be send in full but still this would likely cut down the bandwidth by close to 50% with just that small change.

I would like to be able to make arbitrary changes to my database's schema without needing to delete all the data. I would like to be able to write module code to migrate the data from the old schema to the new one.

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.

the current SQL engine is very limited and i heard that it is one of the oldest part of the codebase. it would be great to get all the basic sql features like arithmetic, IN, multiple JOIN, SpacetimeType support and so on.

# use case Let's say I have a list of users and I want to search after the username. Currently I am either forced to have the entire list filtered on the client or I have a procedure that iterates over the entire user list and does manual filtering. It would be nice to have an out of the box operator for this common task. # changes I would hope for the operator to be available in reducers / procedures, the query builder and SQL queries # benefit this would make a common use case easier, lead to better performance and it helps Spacetimedb become more compatible with the complete sql syntax

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 :>

After you manually insert anything in a auto inc pk column you boobytrapped your table waiting for auto pk insertions to collide nastily. Lots of users have had to roll their own collision prevention or even create their own PK tables. As if you ever have pk autoinc columns and manual data migration you will run into this problem. Auto Inc PKs should skip the value and attempt the next one or start at the max value or smth. GL!

games need a world map and ranged indexes are often not good enough to do physics on it as it is not easy to cache the filtered data between iterations. besides that it is also not possible to do two ranged indexes in the same filter (x and y +-10 cells). this would also be really helpful to write a stdb optimised physics engine further down the path.

procedures have a very high potential for server side computation that takes longer than a ms or needs data that is heavy to calculate/build from the tables. be it physics, npc path finding and behaviour tree updates or other stuff that needs to be updated often with large base data. the problem currently is that procedures don't have a way of checking if they should stop for a publish, wasm rebuild or other stuff like moving of the module from one machine to another. the idea is that we need a st_ table for the procedures that keeps track of all the active procedure instances and that they have a column that the procedure can check with a ctx. function for it to stop and all the data the server requires to forcefully stop the procedure if needed (timeout no response and so on). an example code of the wanted setup would be: ```rust #[procedure] pub fn run_physics_loop(ctx: &mut ProcedureContext, _row: PhysicsLaunch) { let mut world = ctx.with_tx(|tx| { build_world_from_db(tx) // computation/time/size expensive build process }); while not ctx.check_stop(){ // check the st_table if it should stop let inputs = ctx.with_tx(read_pending_inputs); // get input data apply_membership(&mut world, /* ... */); run_substeps(&mut world, &inputs, /* ... */); // do math that takes a while ctx.with_tx(|tx| { write_tick_outputs(tx, /* ... */); }); ctx.sleep_until(procedure_runtime::next_tick_target(ctx.timestamp, PHYSICS_INTERVAL)); } } ``` this setup can speed up physics by over 1000x compared to rebuilding the physics world each tick inside a reducer and the expensive calculations don't block other reducers while it is running.