Skip to content

Conversation

frrist
Copy link
Member

@frrist frrist commented Mar 10, 2022

@frrist frrist requested review from iand and placer14 March 10, 2022 01:14
@frrist frrist self-assigned this Mar 10, 2022
Copy link
Contributor

@placer14 placer14 left a comment

Choose a reason for hiding this comment

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

The error messages are quite verbose. :D LGTM

@iand
Copy link
Contributor

iand commented Mar 10, 2022

Why not fix model.OldestSupportedSchemaVersion to be correct?

@frrist
Copy link
Member Author

frrist commented Mar 10, 2022

The error messages are quite verbose. :D LGTM

Yeah.. my thinking was since they are returned directly to the user it would be better to make them more descriptive. Callers of validateDatabaseSchemaVersion can still make assertions on the type of error since the returned error wraps ErrSchemaTooOld and ErrSchemaTooNew

Why not fix model.OldestSupportedSchemaVersion to be correct?

I'm not sure what the value should be. The change here forces lily and the database to be on the same version, and I think this is the correct behavior, what do you think? We could keep model.OldestSupportedSchemaVersion around, but that will require implementers to remember to update it each time a migration patch is added, which is error prone.

@frrist frrist merged commit 3435a57 into master Apr 25, 2022
@frrist frrist deleted the frrist/fix/909 branch April 25, 2022 23:02
frrist added a commit that referenced this pull request Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lily runs without error against old schema versions
3 participants