Roman, I've filed a ticket for C++: [1]
[1] - https://issues.apache.org/jira/browse/IGNITE-11027 Best Regards, Igor On Tue, Jan 22, 2019 at 12:55 PM Roman Shtykh <rsht...@yahoo.com.invalid> wrote: > Igor, I see. How about having a warning if `BinaryConfiguration` is not > provided explicitly to at least raise attention? And creating a JIRA issue > for C++ clients -- after it resolves we can probably switch it to cluster > default. > > -- > Roman Shtykh > > On Monday, January 21, 2019, 7:04:30 p.m. GMT+9, Igor Sapego < > isap...@apache.org> wrote: > > I believe, it was set to false by default as it was kind of experimental > optimisation. > Also, I've checked right now and it seems that C++ clients (thick and > thin)do not yet support compact footers. It may also be a blocker to set > compactfooters to true by default. > Best Regards,Igor > > On Sat, Jan 19, 2019 at 6:52 AM Roman Shtykh <rsht...@yahoo.com.invalid> > wrote: > > Thank you for the explanation. But here is the problem is not exactly with > deserialization but with that a user-defined key is being marshalled to a > binary object with the compact footer set to true, while the key for > putting has the footer set to false (which is server default). Thus we have > a different thing for the key when we try to retrieve and getting null. > Therefore, I suppose switching client to server defaults is what has to be > done. If the user decides to switch to full schema mode, at least he/she > will be aware of it. And for deserialization, the schema will be retrieved, > as you explained. What do you think? > > -- Roman > On Friday, January 18, 2019, 10:52:11 p.m. GMT+9, Vladimir Ozerov < > voze...@gridgain.com> wrote: > > "Compact footer" is optimization which saves a lot of space. Object > serialized in this form do not have the full information required for > deserialization. Metadata necessary for deserialization (aka "schema") is > located on cluster nodes. For this client it could be requested through > special command. Pleass see ClientOperation.GET_BINARY_TYPE as a starting > point. > On Fri, Jan 18, 2019 at 1:32 PM Igor Sapego <isap...@apache.org> wrote: > > I'm not sure, that such a change should be done in minor release, maybe in > 3.0 > Vova, what do you think? It was you, who designed and developed compact > footer, right? > Best Regards,Igor > > On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh <rsht...@yahoo.com.invalid> > wrote: > > > I believe it has something to do with backward compatibility.That's what > I would like to know.If there's no strong reason to set it to false, it > should be as Ignite's default -- that's what a user would expect. And if > the user changes the configuration at the cluster, he/she will be aware of > that and change it at thin client.If we cannot set it to Ignite's default, > we can add a log message saying we force it to false. > > -- > Roman > > > On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego < > isap...@apache.org> wrote: > > First of all, I do not like that thin client is silently returns null. It > should be fixed. > For the compact footer being set to false by default - I believe it has > something to do withbackward compatibility. > Best Regards,Igor > > On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh <rsht...@yahoo.com.invalid> > wrote: > > Igniters, > After putting some data with a user-defined key with a thick client, it's > impossible to retrieve it with a thin client. > https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was > a bug, so I first reported the issue to the user ml, Mikhail thanks for > checking and the jira issue) > That happens because for Ignite `compactFooter` is `true` by default, but > `ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is > not created explicitly (see ClientBinaryMarshaller#createImpl). > Any reason to force it to false? I would like to align it with Ignite > defaults (by setting to true). > > -- Roman > > > > >
