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

core: Ignore indexed-only constraints when updating #734

Merged
merged 1 commit into from
Feb 16, 2024
Merged

Conversation

kim
Copy link
Contributor

@kim kim commented Jan 19, 2024

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.

/// corresponding [`Constraints::indexed()`] constraint (it will be unset).
/// The schema obtained from the database **will** have one such constraint,
/// however.
///
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, is better.

Copy link
Contributor

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.

Copy link
Contributor

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.

@bfops bfops added bugfix Fixes something that was expected to work differently release-any To be landed in any release window release-0.8.2-hotfix labels Feb 8, 2024
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.

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.

index_id: IndexId(68),
table_id: TableId(42),
index_type: IndexType::BTree,
index_name: "bobson_dugnutt".into(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol

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.

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.
@kim kim enabled auto-merge February 16, 2024 07:42
@kim kim added this pull request to the merge queue Feb 16, 2024
Merged via the queue into master with commit 09a495f Feb 16, 2024
6 checks passed
kim added a commit that referenced this pull request Mar 14, 2024
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.
kim added a commit that referenced this pull request Mar 15, 2024
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.
github-merge-queue bot pushed a commit that referenced this pull request Mar 15, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix Fixes something that was expected to work differently release-any To be landed in any release window
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants