-
Notifications
You must be signed in to change notification settings - Fork 257
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
[Scala] support default not-null value in COMPATIBLE mode. #1683
Comments
Hi @LoranceChen , thanks for bring this up. It's very necessary to support this in Apache Fury. Scala didn't provide a method to construct object with default value at bytecode level. It generate bytecode to invoke constructor with all parameters provided, and default params are provided at callsite. If we need to provide default value when creating object, we need to extract the default value. Fortunately, scala generate a case class SomeClass(v: List[IdAnyVal], x:Int=1)
// Callsite bytecode
34: getstatic #131 // Field org/apache/fury/serializer/SomeClass$.MODULE$:Lorg/apache/fury/serializer/SomeClass$;
37: invokevirtual #135 // Method org/apache/fury/serializer/SomeClass$.apply$default$2:()I
40: invokespecial #138 // Method org/apache/fury/serializer/SomeClass."<init>":(Lscala/collection/immutable/List;I)V
43: putstatic #87 // Field p:Lorg/apache/fury/serializer/SomeClass;
46: getstatic #143 // Field scala/Predef$.MODULE$:Lscala/Predef$; We may can detect whether such method exists to know which parameter has default value, and provide it as default value when constructing object. This will take some horse work. We don't have time for this currently. Would you like to contribute to this? The |
Hi, great to see can solve it. |
If the field doesn't exist in serialization process, but does exist in deserialization process, we can invoke method like |
Hi, @chaokunyang , do you some advice to debug the codegen init process? Thanks |
You can configure FURY_CODE_DIR environment variable to set generated code dir, if you set it to src directory, then you can debug it in IDE when rerun the code |
Hi @LoranceChen , are you still working on this issue? |
Currently, for scala, add new field and deserialize from old binary data will get a
null
as new field value. But avoid null is a good practice in scala language.I think it's better using default value our a empty value to set the new field. Such as give the result:
// deserPerson: Person(1,true,some text, "default d")
And if there not a default value in the field define, can give a empty value. For String is
""
will be better for null.If the new field is a structure, can using a default value to instance this one.
case class Foo(a: String, b: Int)
can setting the default value asFoo("", 0)
However, for some performance care scenario. Using
null
should be better and handle by developer.I'm advice add a new configuration to decide using the default value or
null
for new field.The text was updated successfully, but these errors were encountered: