During review I faced the problem, that I have not enough experience to answer.
So, it will be great, if someone who has deep experience with Binary marshaller could help us. --------------------------- > How about such limitations of Binary Marshaller: > 1) Fields or types with the same name hash are not allowed. > 2) BinaryObject format does not allow same field names on different levels of a class hierarchy. > 3) Externalizable interface is ignored by default. If BinaryObject format is used, Externalizable > classes will be written the same way as if they were Serializable, without writeExternal() and > readExternal() methods. If for some reason this does not work for you, you should implement > Binarylizable interface for your classes, plug in a custom BinarySerializer or switch to the > OptimizedMarshaller. > There are no such limitations in Kryo and Java serialization. > The next concern is that you need *Ignite Core* module, which is rather huge (about 7.3MB) if > you want to build ETL script which will consume data persisted into Cassandra by Ignite Binary > Marshaller. > By the way, does Ignite plan to support backward compatibility for data persisted using Binary > Marshaller? I mean the situation when some objects were persisted into Cassandra using old > version of Binary Marshaller and then Ignite cluster was upgraded to new version. Kryo and > Java serialization handles this situation and provides backward compatibility. > May be it's better just to add one more serializer implementation which will use Binary Marshaller? > By the way are there any samples in the code how to use Binary Marshaller just to > serialize/deserialize arbitrary object? Binary Marshaller documentation says that all such > operation performed internally inside Ignite when we using BinaryObject, but in my case I am > interested in rather low-level serialization/deserialization API/ Regards, Igor Rudyak -------------------------------------------- Hi Igor! I moved discussion to dev list. >>> The next concern is that you need *Ignite Core* module We could not avoid adding this module because All base cache store classes declared in that module, so I think this module will *be always imported*. As for other points, I hope community will help us. -- Alexey Kuznetsov GridGain Systems www.gridgain.com
