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

Justin Edelson commented on OAK-2028:
-------------------------------------

[~tmueller] I think the question there would be -- how do you know that the 
results aren't "really" ordered? IIUC, the idea of this issue is that the 
application developer would know that milliseconds are never displayed and so 
they will configure the index to only have seconds precision (or minutes maybe 
if they knew that seconds were never displayed, etc.). I would expect that the 
additional sorting you mention would have some non-trivial cost associated with 
it (especially for large result sets), so why not allow the developer/deployer 
to make this determination?

Personally, I'm less concerned about what the default is...

> 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)

Reply via email to