-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring bootstrapping and adding full support for constraints & multi-column indexes #267
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've read through most of this PR. If the bootstrapping works, it definitely looks more cleaned up and less fragile than before so that is great. I also think create_table
is cleaner as well.
The one major piece of feedback is that I think we should get rid of ColumnIndexAttributes
in this PR. It doesn't make any sense.
The situation should be:
table constraints:
- unique (multi-column)
- primary_key (multi-column, implies unique)
table indexes:
- btree (multi-column)
- hash (multi-column, not in this PR)
column attributes:
- auto_inc
crates/cli/Cargo.toml
Outdated
@@ -17,6 +17,7 @@ bench = false | |||
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html | |||
|
|||
[dependencies] | |||
spacetimedb-core = { path = "../core", version = "0.6.0" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need core?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For access decode_token
. This is unrelated to this PR but could be refactored later?
ColumnIndexAttribute::PRIMARY_KEY_AUTO, | ||
)]) | ||
.with_indexes(&[IndexDef::for_sys_column(ST_TABLES_NAME, StTableFields::TableName, true)]) | ||
.into_schema(ST_TABLES_ID.0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh this is fancy! Makes sense.
.with_constraints(&[ConstraintDef::for_sys_column( | ||
ST_TABLES_NAME, | ||
StTableFields::TableId, | ||
ColumnIndexAttribute::PRIMARY_KEY_AUTO, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really think this should be two constraints:
UNIQUE
AUTO_INC
(not really even a constraint)
I would even make the change to deprecate ColumnIndexAttribute
in this PR. The bitflag thing is not the direction we want to go if we have the ability to add multiple constraints. I'm okay with doing that in a future PR as long as we leave a comment in this PR that we intend to make the change.
// }, | ||
pos: value.col_id as usize, | ||
impl ColumnSchema { | ||
pub fn from_def(table_id: u32, col_pos: u32, column: ColumnDef) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use the From
trait? This is more explicit I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, also to use From
in callers it needs to use a tuple so I think this looks cleaner.
9b52f7e
to
25a638c
Compare
e205895
to
eb018db
Compare
d66632a
to
29b517c
Compare
9e7d30e
to
e5a2de7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting changes mainly because I think this breaks the update_database
logic.
for idx in unique_it { | ||
let is_unique = idx.is_unique; | ||
|
||
//Skip multi_column indexes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
I think this needs more commentary. The the multi-column indexes could be .filter
ed out from the iterator even.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the csharp
code can deal with it. I will wait to confirm if I can remove this restriction...
fn scan_st_tables<'a>(&'a self, tx: &'a Self::TxId) -> Result<Vec<StTableRow<String>>>; | ||
|
||
fn scan_st_columns<'a>(&'a self, tx: &'a Self::TxId) -> Result<Vec<StColumnRow<String>>>; | ||
|
||
fn scan_st_constraints<'a>(&'a self, tx: &'a Self::TxId) -> Result<Vec<StConstraintRow<String>>>; | ||
|
||
fn scan_st_sequences<'a>(&'a self, tx: &'a Self::TxId) -> Result<Vec<StSequenceRow<String>>>; | ||
|
||
fn scan_st_indexes<'a>(&'a self, tx: &'a Self::TxId) -> Result<Vec<StIndexRow<String>>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find those a little unfortunate:
- Do we really need this as public API?
- Why
scan_*
whenVec
is returned? - How will we decide which system tables can be collected, and ensure that new ones get a method here? Could we not pair st table ids with row types using associated types, and have a single method which works for all system tables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I created a utility struct instead.
// state should be initialized eagerly here? | ||
// We don't add the row here but with `MutProgrammable::set_program_hash`, but we need to register the table | ||
// in the internal state. | ||
// TODO: This should be moved here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean set_program_hash should be moved here? That would only be possible if we could bootstrap in a transaction -- otherwise, if the init reducer fails, the hash may point to nothing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, I remove the TODO then.
crates/vm/src/program.rs
Outdated
@@ -2,7 +2,7 @@ | |||
//! | |||
//! It carries an [EnvDb] with the functions, idents, types. | |||
use spacetimedb_lib::identity::AuthCtx; | |||
use spacetimedb_lib::relation::{MemTable, RelIter, Relation, Table}; | |||
use spacetimedb_sats::relation::{MemTable, RelIter, Relation, Table}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels rather strange that MemTable
should be part of SATS.
crates/vm/src/dsl.rs
Outdated
pub fn db_table(head: ProductType, name: &str, table_id: TableId) -> DbTable { | ||
db_table_raw(head, name, table_id, StTableType::User, StAccess::for_name(name)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revert this please; seems like the rebase went somewhat wrong. We should not be passing &str
only to clone it later on. It's better to pass owned stuff directly.
bf9e4c2
to
9328408
Compare
14938f0
to
19c2847
Compare
2fc996c
to
419cfca
Compare
Description of Changes
NOT REVIEW IT YET!
Note: This is a multi-step set of PRs to bring constraints + multi-column indexes
Step:
API and ABI
If the API is breaking, please state below what will break