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 <[email protected]> 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 <[email protected]>: > > > 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 > > >
