Vladimir, Thanks for reply. In any case, we'll break compatibility by introducing new feature in marshalling. But both approaches preserve backward compatibility.
I deemed it's unusual to make two differerent type markers (flags) for single datatype. I can't see the source right now, but I'm unsure whether it's possible to map two flags to single type in marshaller implementation. 25 июля 2017 г. 20:13 пользователь "Vladimir Ozerov" <voze...@gridgain.com> написал: > Andrey, > > You cannot have optional part in the middle as it will break compatibility > in dangerous way, probably leading to node crash. Also having INT (4 > bytes) > looks too much for me. > > Instead, I would add new type "encoded string": > 1 byte - type > 1 byte - encoding code, map frequently used encodings to some byte value; > also have a special value, meaning that encoding will be written as string > afterwards, this way we will support any encoding out of the box > [optional] encoding name > 4 bytes - string length > Finally - string bytes > > Vladimir. > > вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=20039&i=0>>: > > > I apologize for damaged formatting. Below is my message as it should be. > > > > > > Hi Igniters, > > > > I'd like to discuss future changes related to https://issues.apache.org/ > > jira/browse/IGNITE-5655 > > <https://issues.apache.org/jira/browse/IGNITE-5655>. > > > > Is it really good idea to introduce new flag (ENCODED_STRING) for > existing > > String datatype? It's possible to use existing STRING flag at negligible > > performance cost. > > > > Currently, utf-8-encoded string looks like > > > > byteFlag nonNegativeIntStrLen bytes > > > > This format can be backward compatibly extended to > > > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes > > > > Next, I suggest to add new BinaryConfiguration property for encoding to > use > > instead of using global property. It seems to be more convenient for > user. > > > > I'll appreciate your feedback. > > > > 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=20039&i=1>>: > > > > > Hi Igniters,I'd like to discuss future changes related to IGNITE-5655 > > > <https://issues.apache.org/jira/browse/IGNITE-5655> . Is it really > good > > > idea to introduce new flag (ENCODED_STRING) for existing String > datatype? > > > It's possible to use existing STRING flag at negligible performance > cost. > > > Currently, utf-8-encoded string looks like > > > byteFlag nonNegativeIntStrLen bytes > > > This format can be backward compatibly extended to > > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes > > > Next, I suggest to add new BinaryConfiguration property for encoding > to > > use > > > instead of using global property. It seems to be more convenient for > > > user.I'll appreciate your feedback. > > > > > > > > > > > > ----- > > > Best regards, > > > Andrey Kuznetsov. > > > -- > > > View this message in context: http://apache-ignite- > > > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding- > > > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html > > > Sent from the Apache Ignite Developers mailing list archive at > > Nabble.com. > > > > > > > > > > -- > > Best regards, > > Andrey Kuznetsov. > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://apache-ignite-developers.2346864.n4.nabble. > com/Non-UTF-8-string-encoding-support-in-BinaryMarshaller- > IGNITE-5655-tp20024p20039.html > To unsubscribe from Non-UTF-8 string encoding support in BinaryMarshaller > (IGNITE-5655), click here > <http://apache-ignite-developers.2346864.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=20024&code=c3RrdXptYUBnbWFpbC5jb218MjAwMjR8LTUwMjc0NDk4NA==> > . > NAML > <http://apache-ignite-developers.2346864.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >