-
Notifications
You must be signed in to change notification settings - Fork 39
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
Search by class name instead of the class itself #64
Conversation
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.
Thanks for the PR -- this has been on the radar for a while and it will be great to handle these types of cases.
Just a small syntax suggestion that can avoid mutating a local variable by using more idiomatic JS -- and 1 question about why we changed how the Schema type is being exported; otherwise I think it would be great to get this landed.
I tend to lean towards this being a breaking change/major release, though, since it fundamentally changes the behaviour of the library; previously there was an implicit guarantee that any serialization done by Borsh would absolutely 100% of the time serialize the exact class instances provided in the schema, and error if any other class was provided even if it happened to have the same constructor name. With this change, no error would be thrown and Borsh will make a best-effort to serialize using any constructor that happens to have the same name as the constructor in the schema, even if it might be a totally different class that might serialize data in an entirely different way.
Co-authored-by: Daryl Collins <daryl@darylcollins.com>
Co-authored-by: Daryl Collins <daryl@darylcollins.com>
@MaximusHaximus while I agree that, in practice, it is a breaking change (since there was an implicit guarantee), I do not see such guarantee as a fundamental aspect of the library for the library users... I personally see it more as a bug. Specially since the error on (de)serialisation should be dictated by the schema itself, more than the specific Moreover, I do not know (nor expect to be honest to find) anyone to have wanted (or relied on) the specific feature of "index schemas by exact Class", while I do know of many multiple instances in which the behaviour was more a detriment or a bug. Because of this, I would expect a "minor" or "fix" release to create more well than harm (actually, I would expect it to create 0 problems). Of course my view is biased, and I might be very wrong. |
I think this is a breaking change too. While it may not lead to breaking behaviors for most use cases, include different version of libraries shipped with same schema of Making it a breaking change will explicitly ask users to examine their use case, and for most users it should be no additional work. |
closing in favor of #65 |
Right now we are getting lots of errors when trying to deserialise the exact same class across different versions of
near-api-js
,near-social-vm
and others, since theSCHEMA
indexes by theClass
itself.Therefore, I have changed the search inside the schema, so we look for the Class name instead of the Class. In this way, different versions of
Transaction
will point to the same schema.This is a non breaking change that solves the problem without changing the Schemas, nor the expected behaviour of the serialised.