[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919181#comment-13919181
]
Thomas Mueller commented on OAK-1263:
-------------------------------------
Your new patch still has some unnecessary formatting changes, for example the
very first lines of the patch, IndexUtils. getOrCreateOakIndex.
Some more comments:
It looks like you are using 3 spaces indentation, while in Oak we use 4 spaces.
Could you use 4 spaces as well please?
Some lines are over 200 characters long. Could we use a line length of 100
characters (the Eclipse default is 80, and Google uses 80 or 100)? Some if the
long lines are due to formatting changes of existing code.
{noformat}
if(Strings.isNullOrEmpty(value)){
{noformat}
Could you use the following instead (Eclipse and Google code conventions):
{noformat}
if (Strings.isNullOrEmpty(value)) {
{noformat}
Other spacing is inconsistent, for example:
{noformat}
+ pns = Collections.singleton(value);
+ this.properlyConfigured=true;
{noformat}
Could you use the following:
{noformat}
+ pns = Collections.singleton(value);
+ this.properlyConfigured = true; // <= spaces
{noformat}
Could you use spaces before commas?
{noformat}
+ /**
+ * retrieve the type of the index
+ *
+ * @return
+ */
{noformat}
I would prefer the following:
{noformat}
+ /**
+ * Retrieve the type of the index.
+ *
+ * @return the type
+ */
{noformat}
> optimize oak index to support 'fast ORDER BY' queries to support sorting &
> pagination for large set of children
> ---------------------------------------------------------------------------------------------------------------
>
> Key: OAK-1263
> URL: https://issues.apache.org/jira/browse/OAK-1263
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Affects Versions: 0.12
> Reporter: Stefan Egli
> Assignee: Alex Parvulescu
> Fix For: 0.18
>
> Attachments: OAK-1263-r1.patch, OAK-1263-r1a.patch,
> benchmark-20140228112150.log, benchmark-20140228120718.log,
> benchmark-20140228125248.log
>
>
> We have a use case where we'd like to be able to use an index in a
> "pagination-like" fashion. That is, we'd like to be able to have an index on
> a subtree on a certain property, and then run a query which does ORDER BY
> that property combined with OFFSET. That way, essentially allowing pagination
> of child nodes of a particular parent based on 'sorted by a certain property'.
> AFAIU currently the oak index is not optimized to support ORDER BY queries in
> a fast manner. The index keeps 'the child nodes unsorted', ie to process an
> ORDER BY, the child nodes would have to be 'manually sorted' which can result
> in bad performance given a large number of child nodes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
