Encoding *must not* be added to per-class or per-field level, this is wrong.
It should be added to per-cache level, and to per-cache-column level in future. пт, 28 июля 2017 г. в 14:27, Andrey Kuznetsov <stku...@gmail.com>: > We discussed this with Pavel and Anton just a moment ago. Summary follows. > > - New byte "flag" is to be added (ENCODED_STRING) > - 'Encoding' property is to be added at > -- global level (BinaryConfiguration) > -- per-class level (BinaryTypeConfiguration) > -- per-field level (BinaryTypeConfiguration) > > 2017-07-28 14:15 GMT+03:00 Vladimir Ozerov [via Apache Ignite Developers] < > ml+s2346864n20159...@n4.nabble.com>: > > > As Pavel mentioned, Marshaller should not be tied to cache, BinaryObject > > should be self-explanatory, i.e. containing all information necessary for > > unmarshalling. This is an absolute requirement. > > > > We will have one extra byte for in serialized form, meaning that > advantage > > of custom encoding will become evident for all strings with length >= 1, > > which is perfectly fine. I do not quite understand what are we arguing > > about. > > > > As far as configuration, we can do it as follows: > > > > 1) Add global encoding, UTF8 by default. > > 2) Add per-cache encoding. > > 3) Add encoding to JDBC and ODBC driver properties. > > > > This should be enough. > > > > > -- > 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-tp20024p20161.html > Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
