Skip to content
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

Closed
wants to merge 0 commits into from

Conversation

mamcx
Copy link
Contributor

@mamcx mamcx commented Sep 6, 2023

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

  • This is a breaking change to the module ABI
  • This is a breaking change to the module API
  • This is a breaking change to the ClientAPI
  • This is a breaking change to the SDK API

If the API is breaking, please state below what will break

@mamcx mamcx requested a review from cloutiertyler September 6, 2023 18:57
@mamcx mamcx mentioned this pull request Sep 8, 2023
9 tasks
@cloutiertyler cloutiertyler changed the base branch from master to mamcx/multi-column-index September 9, 2023 00:03
@cloutiertyler cloutiertyler changed the base branch from mamcx/multi-column-index to master September 9, 2023 00:04
Copy link
Contributor

@cloutiertyler cloutiertyler left a 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

@@ -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" }
Copy link
Contributor

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?

Copy link
Contributor Author

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)
Copy link
Contributor

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,
Copy link
Contributor

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@mamcx mamcx force-pushed the mamcx/multi-column-schema branch 2 times, most recently from 9b52f7e to 25a638c Compare September 14, 2023 18:11
@mamcx mamcx force-pushed the mamcx/multi-column-schema branch 2 times, most recently from e205895 to eb018db Compare September 25, 2023 19:51
@mamcx mamcx marked this pull request as ready for review September 25, 2023 20:30
@kim kim mentioned this pull request Sep 29, 2023
4 tasks
@mamcx mamcx force-pushed the mamcx/multi-column-schema branch from d66632a to 29b517c Compare October 10, 2023 22:02
@mamcx mamcx removed the invalid label Oct 10, 2023
@mamcx mamcx force-pushed the mamcx/multi-column-schema branch from 9e7d30e to e5a2de7 Compare October 10, 2023 23:11
kim
kim previously requested changes Oct 11, 2023
Copy link
Contributor

@kim kim left a 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
Copy link
Contributor

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 .filtered out from the iterator even.

Copy link
Contributor Author

@mamcx mamcx Oct 11, 2023

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

Comment on lines 101 to 109
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>>>;
Copy link
Contributor

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_* when Vec 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?

Copy link
Contributor Author

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?
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@kim kim self-requested a review October 12, 2023 05:45
@kim kim dismissed their stale review October 12, 2023 05:47

update_database should now work correctly

@@ -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};
Copy link
Contributor

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.

Comment on lines 50 to 52
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))
}
Copy link
Contributor

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.

@mamcx mamcx force-pushed the mamcx/multi-column-schema branch 2 times, most recently from bf9e4c2 to 9328408 Compare October 13, 2023 19:39
@mamcx mamcx mentioned this pull request Oct 17, 2023
8 tasks
@mamcx mamcx mentioned this pull request Oct 26, 2023
4 tasks
@mamcx mamcx self-assigned this Nov 8, 2023
@mamcx mamcx added the abi-break A PR that makes an ABI breaking change label Nov 8, 2023
@mamcx mamcx marked this pull request as draft November 17, 2023 23:23
@mamcx mamcx force-pushed the mamcx/multi-column-schema branch from 14938f0 to 19c2847 Compare November 17, 2023 23:25
@mamcx mamcx closed this Nov 22, 2023
@mamcx mamcx force-pushed the mamcx/multi-column-schema branch from 2fc996c to 419cfca Compare November 22, 2023 17:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abi-break A PR that makes an ABI breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants