I don't understand why this encoding is done on per-object and not on per-cache level. Shouldn't the column-to-encoding mapping be defined at cache level configuration?
On Tue, Jul 25, 2017 at 12:13 PM, Vladimir Ozerov <voze...@gridgain.com> wrote: > 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 <stku...@gmail.com>: > > > 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 <stku...@gmail.com>: > > > > > 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. > > >
