Hi,
null fields are taken into account. So you should have this issue only if
there is always different set of fields provided to a builder for the same
type. Is this your case or you have smth different?
-Val
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Bin
Hi vkulichenko I am having a similar problem with BinaryObjects. I am
building binaryobjects off of DB results or Json results where columns may
be null. It seems like for binary objects you just don't set the null
columns. When I build objects this way I constantly see communication among
the n
Hi,
BinaryObject is designed to represent POJOs in binary format, in this case
schema change is generally a very rare event, so there is no performance
concern about metadata update. You use case is more specific and thus
requires specific solution.
And btw, I'm not sure I understand the differen
I need BinaryObject to process ScanQueries on data with dynamic categories
list. There are 30 different categories at current case.
My Task is to calculate amount of persons in each category, so *map* is not
working for me.
try (QueryCursor cursor = cache.query(new ScanQuery((k,
p) -> p.hasField(
Agree with Andrey. This use case doesn't look like a good fit for
BinaryObject, is there any particular reason for using it? Is Map not
working for you?
-Val
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/BinaryObject-performance-issue-tp4375p4392.html
Sent fro
Hello,
I guess the problem may be with the way you build the binary object - by using
the integers as field names. It forces Ignite to execute a global transaction
to update the "category" type's metadata every time you invoke binary.build().
The update is required because the schema of the new
