-
Notifications
You must be signed in to change notification settings - Fork 110
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
core: Ignore indexed
-only constraints when updating
#734
Conversation
17197d1
to
974f751
Compare
crates/core/src/db/update.rs
Outdated
/// corresponding [`Constraints::indexed()`] constraint (it will be unset). | ||
/// The schema obtained from the database **will** have one such constraint, | ||
/// however. | ||
/// |
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.
This is because the conversion into TableSchema
fills that info.
TableDef
is meant to be a partially defined schema that is resolved/qualified when converted to TableSchema
. See TableSchema::from_def
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.
Are you suggesting to compare TableSchema instead?
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, is better.
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.
The problem with this is that what the module produces is not a TableSchema
. The module only specifies a TableDef
, so by some mechanism we need to compare that to the existing schema (or at least the old def) to find out what changed. You'd have to create a fake TableSchema
for the new module to compare against.
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.
The real problem is that we're not being very careful about what is actual database schema (the thing which requires data migration if it changes) and our various attributes (autoinc) or optimizations (indexes).
Indexes are not really part of the schema of a table in the precise meaning of the term schema, neither are attributes.
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.
This looks good to me, but please read the comments I posted inline.
We will have to have a proper proposal on how we should handle this.
974f751
to
f93f8c2
Compare
index_id: IndexId(68), | ||
table_id: TableId(42), | ||
index_type: IndexType::BTree, | ||
index_name: "bobson_dugnutt".into(), |
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.
lol
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.
Well it certainly does simply things and I appreciate the tests.
Compare `TableSchema` instead of `TableDef`, which should reject all modifications to a table. Note that the values require conversion for both the module and database schema to be comparable. With this change, updating a module which only adds tables or modifies reducers will be possible, but any change (including indexes, constraints, etc) to an existing table will fail the update.
f93f8c2
to
0780c0b
Compare
It turns out that the changes introduced in #734 do not result in more reliable detection of incompatible schema updates. This is because the datastructures involved can be converted into each other, but that conversion is not bijective. Fix this by manually adjusting the schema of the existing table to be comparable to the proposed table. Also log details about a schema mismatch to the user-retrievable database log, in unified diff format.
It turns out that the changes introduced in #734 do not result in more reliable detection of incompatible schema updates. This is because the datastructures involved can be converted into each other, but that conversion is not bijective. Fix this by manually adjusting the schema of the existing table to be comparable to the proposed table. Also log details about a schema mismatch to the user-retrievable database log, in unified diff format.
It turns out that the changes introduced in #734 do not result in more reliable detection of incompatible schema updates. This is because the datastructures involved can be converted into each other, but that conversion is not bijective. Fix this by manually adjusting the schema of the existing table to be comparable to the proposed table. Also log details about a schema mismatch to the user-retrievable database log, in unified diff format.
As explained in the commentary.
This will allow updating a module which introduces an index via
#[spacetimedb(index, ..)]
, but it will not create that index.