[
https://issues.apache.org/jira/browse/OAK-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125381#comment-14125381
]
Davide Giannella commented on OAK-2028:
---------------------------------------
The key thing here is to give flexibility and improve (maybe) a bit of
performances.
In the vast majority of real world scenarios the precision below the
second for sorting or even below the minute for range queries are not
really needed.
If that would work out better, we could have the default to {{full}}
(as it is now) leaving to the consumer to define the index accordingly
to his needs. It will be then up to the consumer to define if a bucket
of a second is acceptable or not.
Would that be fine?
> 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)
