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

Conversion callback for version tolerance #95

Open
rikimaru0345 opened this issue May 14, 2021 · 0 comments
Open

Conversion callback for version tolerance #95

rikimaru0345 opened this issue May 14, 2021 · 0 comments
Assignees

Comments

@rikimaru0345
Copy link
Owner

When serializes some class with version tolerance and then changes the type (and only the type) of some field inside that class, Ceras won't be able to do the conversion on its own.

Even for simple stuff it'd need to make assumptions, e.g. rounding for float a; => int a;.
And for stuff like string a; => SomeClass a; its pretty much impossible.

Ceras should probably have a callback that allows the user to convert some old properties to a new type.
The conversion callback stuff could look something like

void Convert(ConversionContext ctx); // provided by user


class ConversionContext {
  struct DeserializedEntry {
    string TypeName; // full type name
    string MemberName; // name of field or property
    object Value; // deserialized value; schema is embedded so ceras should be able to read it
  }

  string DeserializedTypeName; // type name that was originally used to write that data
  List<DeserializedEntry> DeserializedData;

  // Probably also need some way to tell the user where to put the result (target object, and where to set it, on what field/property in that target object). But that wouldn't really be compatible with structs...
  // maybe the context could be a ref struct or something?
}

For types that only contain primitive types that should be easy.
But for types that contain class/struct members that won't work.
So we'll probably have to make some sort of DeserializedObjectData that contains the type name and all fields...
But that most likely won't be super comfortable to use for the end-user implementing the conversion.

@rikimaru0345 rikimaru0345 self-assigned this May 14, 2021
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

No branches or pull requests

1 participant