[jira] [Commented] (OAK-2028) Configurable date precision for ordered index

["Thomas Mueller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125337#comment-14125337 ] 

Thomas Mueller commented on OAK-2028:
-------------------------------------

I consider it a bug if somebody runs a query with "order by lastModified" and then the result is ordered by a truncated version of "lastModified" (depending on the index configuration). If I do "order by", then I expect the result to be really ordered. I think that's doable, even if the "precision" is "seconds". But it would require an addition sorting within the index implementation (only within a key, that is, only if there are actually multiple entries for the same key).

> Configurable date precision for ordered index
> ---------------------------------------------
>
>                 Key: OAK-2028
>                 URL: https://issues.apache.org/jira/browse/OAK-2028
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, query
>            Reporter: Davide Giannella
>
> Currently the ordered index stores the full date as key of the index
> resulting very often in a key for each node as it will be highly
> improbable to have two nodes added at the same millisecond.
> Provide the ordered index with a configuration that will allow the end
> user to decide what precision for date fields to adopt.
> Something like
> {noformat}
> {
>   ...
>   "type" : "ordered",
>   ...
>   "datePrecition" : "second"
> }
> {noformat}
> where the available options will be 
> {noformat}
> year, month, day, hour, minute, second, full
> {noformat}
> with {{second}} as default having therefore the milliseconds always
> ignored.
> By specifying for example {{minute}} it will make the index to ignore
> seconds and milliseconds. The timezone aspect will always be
> considered.
> This will result in smaller and therefore faster indexes with a loss
> in sorting precision depending on the value specified. By having
> seconds for example it will mean that all the nodes added within the
> same second will result in a non-deterministic order.
> See full discussion at http://markmail.org/thread/53ca4mfilm7cvwi2 and
> related issues in the ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)