IEP-66: Thin Client Automatic Binary Configuration

[Pavel Tupitsyn]

Igniters,

Please review the IEP [1] and let me know your thoughts.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration

[Alexey Plekhanov]

Hello Pavel,

Changing the "compact footer" property for an existing database can lead to
compatibility issues. Some clients (at least java) have "false" as the
default value of the "compact footer" property, but the default value for
the server-side is "true". If thin client will receive binary configuration
from the server it will be unable to get values using user-defined type as
a key inserted by previous versions of the client (see [1]).
Also, AFAIK, some clients still don't have compact footer support.
So we should think carefully about how to provide compatibility using this
feature (for example, enable this feature only for clusters with no data
inserted into caches by previous versions of thin clients)

[1]: https://issues.apache.org/jira/browse/IGNITE-10960

пн, 1 февр. 2021 г. в 19:33, Pavel Tupitsyn <[hidden email]>:

> Igniters,
>
> Please review the IEP [1] and let me know your thoughts.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration
>

[Pavel Tupitsyn]

Alex,

This is a very good point, thank you for the heads up.

The proposal does not include changing any existing behavior,
we simply add an operation to the protocol, so there is
no compatibility risk from the server-side changes alone.

However, it looks like only .NET thin client can make use
of the compactFooter flag, since it is true by default there,
and changing from true to false is safe.

Additionally, we can't use the nameMapper value even in .NET,
since it changes the default behavior and potentially breaks
compatibility on existing clusters. All we can do is log a warning.

I've updated the proposal accordingly.


On Tue, Feb 2, 2021 at 9:50 AM Alex Plehanov <[hidden email]>
wrote:

> Hello Pavel,
>
> Changing the "compact footer" property for an existing database can lead to
> compatibility issues. Some clients (at least java) have "false" as the
> default value of the "compact footer" property, but the default value for
> the server-side is "true". If thin client will receive binary configuration
> from the server it will be unable to get values using user-defined type as
> a key inserted by previous versions of the client (see [1]).
> Also, AFAIK, some clients still don't have compact footer support.
> So we should think carefully about how to provide compatibility using this
> feature (for example, enable this feature only for clusters with no data
> inserted into caches by previous versions of thin clients)
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-10960
>
> пн, 1 февр. 2021 г. в 19:33, Pavel Tupitsyn <[hidden email]>:
>
> > Igniters,
> >
> > Please review the IEP [1] and let me know your thoughts.
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration
> >
>

[Igor Sapego-2]

Guys,

I agree with your concerns about backward compatibility, but
I think this can be a good feature that will help us to add support
for compact footer to thin clients that do not support it currently.

Best Regards,
Igor


On Tue, Feb 2, 2021 at 11:49 AM Pavel Tupitsyn <[hidden email]> wrote:

> Alex,
>
> This is a very good point, thank you for the heads up.
>
> The proposal does not include changing any existing behavior,
> we simply add an operation to the protocol, so there is
> no compatibility risk from the server-side changes alone.
>
> However, it looks like only .NET thin client can make use
> of the compactFooter flag, since it is true by default there,
> and changing from true to false is safe.
>
> Additionally, we can't use the nameMapper value even in .NET,
> since it changes the default behavior and potentially breaks
> compatibility on existing clusters. All we can do is log a warning.
>
> I've updated the proposal accordingly.
>
>
> On Tue, Feb 2, 2021 at 9:50 AM Alex Plehanov <[hidden email]>
> wrote:
>
> > Hello Pavel,
> >
> > Changing the "compact footer" property for an existing database can lead
> to
> > compatibility issues. Some clients (at least java) have "false" as the
> > default value of the "compact footer" property, but the default value for
> > the server-side is "true". If thin client will receive binary
> configuration
> > from the server it will be unable to get values using user-defined type
> as
> > a key inserted by previous versions of the client (see [1]).
> > Also, AFAIK, some clients still don't have compact footer support.
> > So we should think carefully about how to provide compatibility using
> this
> > feature (for example, enable this feature only for clusters with no data
> > inserted into caches by previous versions of thin clients)
> >
> > [1]: https://issues.apache.org/jira/browse/IGNITE-10960
> >
> > пн, 1 февр. 2021 г. в 19:33, Pavel Tupitsyn <[hidden email]>:
> >
> > > Igniters,
> > >
> > > Please review the IEP [1] and let me know your thoughts.
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration
> > >
> >
>

[Pavel Tupitsyn]

The changes are ready for review

https://github.com/apache/ignite/pull/8733

On Tue, Feb 2, 2021 at 7:23 PM Igor Sapego <[hidden email]> wrote:

> Guys,
>
> I agree with your concerns about backward compatibility, but
> I think this can be a good feature that will help us to add support
> for compact footer to thin clients that do not support it currently.
>
> Best Regards,
> Igor
>
>
> On Tue, Feb 2, 2021 at 11:49 AM Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > Alex,
> >
> > This is a very good point, thank you for the heads up.
> >
> > The proposal does not include changing any existing behavior,
> > we simply add an operation to the protocol, so there is
> > no compatibility risk from the server-side changes alone.
> >
> > However, it looks like only .NET thin client can make use
> > of the compactFooter flag, since it is true by default there,
> > and changing from true to false is safe.
> >
> > Additionally, we can't use the nameMapper value even in .NET,
> > since it changes the default behavior and potentially breaks
> > compatibility on existing clusters. All we can do is log a warning.
> >
> > I've updated the proposal accordingly.
> >
> >
> > On Tue, Feb 2, 2021 at 9:50 AM Alex Plehanov <[hidden email]>
> > wrote:
> >
> > > Hello Pavel,
> > >
> > > Changing the "compact footer" property for an existing database can
> lead
> > to
> > > compatibility issues. Some clients (at least java) have "false" as the
> > > default value of the "compact footer" property, but the default value
> for
> > > the server-side is "true". If thin client will receive binary
> > configuration
> > > from the server it will be unable to get values using user-defined type
> > as
> > > a key inserted by previous versions of the client (see [1]).
> > > Also, AFAIK, some clients still don't have compact footer support.
> > > So we should think carefully about how to provide compatibility using
> > this
> > > feature (for example, enable this feature only for clusters with no
> data
> > > inserted into caches by previous versions of thin clients)
> > >
> > > [1]: https://issues.apache.org/jira/browse/IGNITE-10960
> > >
> > > пн, 1 февр. 2021 г. в 19:33, Pavel Tupitsyn <[hidden email]>:
> > >
> > > > Igniters,
> > > >
> > > > Please review the IEP [1] and let me know your thoughts.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-66%3A+Thin+Client+Automatic+Binary+Configuration
> > > >
> > >
> >
>