[
https://issues.apache.org/jira/browse/IGNITE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266624#comment-16266624
]
Kirill Shirokov commented on IGNITE-6702:
-----------------------------------------
Thanks for review. Some questions about the style in this product:
1.2) This way you end up with the following:
T1 var1 = getX();
T2 var2 = getY(var1);
T3 var3 = getZ(var2);
Instead of:
T3 var3 = getZ(getY(getX());
or:
T2 var2 = getY(getX());
T3 var3 = getZ(var2);
Is the first style is recommended for this product?
1.3) Then it looks like we have a bit different view on the logic of putting
these empty lines. I'm trying to understand your one:
Why the lines at BPlusTreeSelfTest.java:1653:
long treeSize = tree.size(rowDumper);
long curPutVal = curPutKey.get();
are semantically similiar and don't have a blank line in between, while the
following ones at BPlusTree.cpp:1987:
readUnlock(curPageId, curPage, curPageAddr);
curPageAddr = 0; // Set to zero to avoid double unlocking in finalizer
...are different and have a separating line?
Also I'm trying to avoid style where
we
have
an empty
line
between
every
two
statements.
(while not having blank lines at all is also quite embarassing).
3) We have around 722 TODOs already in the codebase -- should TODOs also be
removed when I work on or touch a method that contains a TODO?
4) What kind of binary compatibility problems they introduced? So, should I
avoid lambdas (when we move to Java 8) / anon. classes in the whole product
(including the tests) or only in the parts that are involved in serialization?
Thank you!
> Get rid of values deserialization in H2TreeIndex.getRowCount
> ------------------------------------------------------------
>
> Key: IGNITE-6702
> URL: https://issues.apache.org/jira/browse/IGNITE-6702
> Project: Ignite
> Issue Type: Improvement
> Components: sql
> Reporter: Semen Boikov
> Assignee: Kirill Shirokov
> Labels: performance
> Fix For: 2.4
>
>
> It seems H2TreeIndex.getRowCount is called for 'select count(*) from x'
> queries, now it is implemented via BPlusTree.find(x, x) method which
> deserializes all values. Actually values are not needed there, need implement
> method on BPlusTree computing size without deserialization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
