Configuration)
> > >>>> -- 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.
> > >>>
> > >>
> >
> >
>
59...@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
> >>>>> u
t;>>>> 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 ar
Currently, marshaller determines the type of field (BYTE, INT, STRING etc.)
only by the Class of data being serialized. It seems rather non-trivial to
manage marshaling parameters at cache creation point. Alternatively, there
exists simple and flexible way: just to introduce new Java type, say,
Str
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.
>
F8 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.
>
t;
> >
> --
> 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.
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.
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 beco
Val, of course other options should be available, such as
BinaryTypeConfiguration,
and maybe field-level and class-level annotations.
On Thu, Jul 27, 2017 at 9:07 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Pavel,
>
> This forces user to implement Binarylizable for whole typ
Pavel,
This forces user to implement Binarylizable for whole type in case they
want to change encoding for one-two fields, right? I really don't like it,
why not add default encoding to BinaryTypeConfiguration?
-Val
On Thu, Jul 27, 2017 at 7:54 AM, Pavel Tupitsyn
wrote:
> > 1 byte for every fi
> 1 byte for every field just for this
GridBinaryMarshaller.STRING data type remains untouched.
We add GridBinaryMarshaller.STRING_ENCODED, which has additional byte for
encoding type.
This means no overhead for existing code.
I think the most common use case is English, which uses 1 byte per char
Pavel, what would be the size overhead? Are we adding 1 byte for every
field just for this? If you would like to have this info in the binary
object directly, can we in this case have some bitmap of field-to-encoding?
D.
On Thu, Jul 27, 2017 at 9:22 AM, Pavel Tupitsyn
wrote:
> I'm not sure I ud
I'm not sure I uderstand how this "per field" configuration is supposed to
be implemented.
* Marshaller is not tied to a cache. It serializes all kinds of things,
like compute job parameters and results.
* Raw mode does not involve field names.
Also it seems like a complicated and expensive soluti
> Igor, it seems like you are advocating the per-cell configuration, not
> per-field one.
True, some terms mismatch here.
> I see your point about C++ and .NET integrations however. Can't we provide
> this info at node-join time or table-creation time? This way all nodes
will
> receive it and you
On Thu, Jul 27, 2017 at 9:04 AM, Igor Sapego wrote:
> Just a note from the platforms guy:
>
> Solution with table-level configuration is going to be significantly
> harder to implement for platforms and ODBC then field-level one.
>
Igor, it seems like you are advocating the per-cell configuratio
Just a note from the platforms guy:
Solution with table-level configuration is going to be significantly
harder to implement for platforms and ODBC then field-level one.
Also, what about binary objects, which are not stored in cache,
but being marshalled?
Best Regards,
Igor
On Wed, Jul 26, 201
On Wed, Jul 26, 2017 at 3:40 AM, Vyacheslav Daradur
wrote:
>
> > Encoding must be set on per field basis. This will give us as most
> flexible
> > solution at the cost of 1-byte overhead.
>
> > Vova, I agree that the encoding should be set on per-field basis, but at
> > the table level, not at a
gt; <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
ss 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
> &
> > > <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.
nNegativeIntStrLen 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 proper
_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 forma
Len 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.
> >
>
> 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
gt; > 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.
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.htm
bal 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
28 matches
Mail list logo
