GitHub user istinnstudio edited a comment on the discussion: (Java/Scala) How do I specify deserialize behavior on schema change?
I have just tested fury as a potential future alternative for the FST library. FST has some kind of support for versioning, supporting only new fields adding. Deleting is not supported. Field rename is possible but changing the field type is like adding a new one. So I end up will "dummy" fields in code, stayed there by mistake or feature update, but there is at least backwards compatibility and old files can be deserialized ok. Old version fields thought should stay for ever in their classes even if they are useless null or empty. FST uses an incremental annotation for this @ Version 1 ... n before any new field declaration. I am hoping at least for a feature like this one or something better or at least example code on how to achieve backwards compatibility in basic class update scenarios. I do not know if there are other better solutions that can handle deleted fields without breaking the deserialization. I also do not know if there is any documentation or code examples of fury th at can help to manage "versioning" scenarios. GitHub link: https://github.com/apache/fury/discussions/1848#discussioncomment-10742759 ---- This is an automatically sent email for commits@fury.apache.org. To unsubscribe, please send an email to: commits-unsubscr...@fury.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@fury.apache.org For additional commands, e-mail: commits-h...@fury.apache.org
