Automatic checking of storage compatibility of structs and enums #261
Conversation
frangio
changed the title
packages/core/src/storage.ts
Outdated
| updated: T[], | ||
| { canGrow }: { canGrow: boolean }, | ||
| ): StorageOperation<T>[] { | ||
| const ops = levenshtein(original, updated, (a, b) => matchStorageField(a, b, { canGrow: false })); |
There was a problem hiding this comment.
Shouldn't canGrow be true for the last item in the storage? Though I'm not sure if that can open the door to other kind of problems, and it's best to be conservative.
There was a problem hiding this comment.
Yeah technically the last item in storage can grow, I think it's safe and I'd love to support it. The issue is that levenshtein calls the match function without any indication that an element is the last one in the layout. We would have to work around that or change the levenshtein function somehow and I decided to go with the simpler conservative choice.
If people run into this limitation we will reconsider!
Amxx
left a comment
Amxx
left a comment
There was a problem hiding this comment.
I don't have a broad enough view to spot any subtle issues / inconsistency in the logic ... but overall, everything looks good at a local level.
|
Thank you so much! @frangio |
Fixes #152
Fixes #95
Fixes #199
Resolves #248
Resolves #249
Deprecation message forKept for when struct members are missing from previous versions.unsafeAllowCustomTypesflag.Should this be considered a breaking change? I've currently made it so that an existing
unsafeAllowCustomTypesflag will be ignored (and I'm additionally planning to make it print a deprecation message). If we assume that users were using this flag with truly compatible types (as intended) this it not a breaking change.