[
https://issues.apache.org/jira/browse/OAK-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056020#comment-14056020
]
Vikas Saurabh commented on OAK-1952:
------------------------------------
Following info is about my use-case:
> Is using an asynchronous index good enough (results might not reflect the
> very latest changes)?
Yes, sure
> Is propertyA is a multi-valued property?
yes, it's a multi-value property. More specifically, I was looking for
searching nodes tagged with cq:tags property
> What data type does it have, or do you need support for multiple data types?
> What are typical values (example values)?
In my case, I was looking for cq:tags='tag:A' OR cq:tags='tag:B'. So, for me,
string would suffice. Also, for my specific case, the property remains same
while I was querying this same property for multiple ORed values
> How many nodes are there in the repository with that property?
I don't have concrete estimates about this :(
> How many values does it typically have per node (min, max, average)?
the nodes of this specific resource type would typically have 2-5 tags
associated with them
> How many distinct values are there?
My guess would be around a 1000 distinct values system wide
> Is the list of values fixed (relatively) fixed or does it change a lot?
The list of distinct values would be pretty much fixed. The association of
these values would change more
> [Query] There should be a way to sort results from query according number of
> properties/predicates match
> --------------------------------------------------------------------------------------------------------
>
> Key: OAK-1952
> URL: https://issues.apache.org/jira/browse/OAK-1952
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Affects Versions: 1.0
> Reporter: Vikas Saurabh
>
> Use Case: Query for value of propertyA for valueA OR valueB OR valueC and
> sort it according to number of matches (ie a node matching all 3 should have
> higher score than those mathing 1 or 2 of those).
> Currently, the only way is to fetch the result from OR query in application
> and then post process it. While this is fine if application is interested in
> all the results. But, if the query wants to fetch a page of that result set
> (result N to result M), then the application still needs to fetch all nodes
> while the platform can (possibly) optimize this internally.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
