And what about non-java platforms? Best regards, Ivan Pavlukhin
пт, 21 февр. 2020 г. в 14:22, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: > > Hello! > > I don't see how we can force users to implement Comparable for BinaryObject > keys, since BinaryObject implementation is not provided by users but by us. > > I think that we, however, could force it for composite non-BinaryObject > keys. > > Regards, > -- > Ilya Kasnacheev > > > пт, 21 февр. 2020 г. в 00:21, Denis Magda <dma...@apache.org>: > > > Hi Ilya, > > > > We can oblige users to implement Comparable if they use BinaryObject keys. > > Ignite can print out a warning if BinaryObject keys passed to putAll > > methods don't do that. > > > > I also wonder how a similar task was solved for Ignite INSERTs. Our engine > > should use BinaryObjects for compound primary keys and insert them at > > patches. That implementation can suggest us some hints. > > > > - > > Denis > > > > > > On Thu, Feb 20, 2020 at 6:53 AM Ilya Kasnacheev <ilya.kasnach...@gmail.com > > > > > wrote: > > > > > Hello! > > > > > > Since we have merged https://issues.apache.org/jira/browse/IGNITE-6804 > > we > > > have to face an embarrassing fact that BinaryObject is not Comparable, > > > i.e., when you do cache.withKeepBinary().putAll(), there are no obvious > > > ways to not get a deadlock (or at least warning) here. > > > > > > One can use LinkedHashMap, but they will have to sort BinaryObject's on > > > their side, which is not trivial. > > > > > > So my proposal is to make BinaryObjectImpl and KeyCacheObject (?) > > > Comparable, by their binary representation. We can't add this constraint > > to > > > BinaryObject since it is a public interface (can we), but we can do that > > > for the implementation types. What do you think? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > >
