cancel
Showing results for 
Search instead for 
Did you mean: 

How do I find all the documents with multiple values in a property?

xkahn
Champ in-the-making
Champ in-the-making

I have a property which can have multiple values, but it typically only has one value. It is defined as:

        <property name="sc:productName">
          <title>Products</title>
          <type>d:text</type>
          <mandatory>false</mandatory>
          <multiple>true</multiple>
          <index enabled="true">
            <atomic>true</atomic>
            <stored>false</stored>
            <tokenised>both</tokenised>
          </index>
        </property>

I need to find all the documents that have more than one assigned product. Or:

num(sc:productName) > 1

How can I do this in a query?

1 ACCEPTED ANSWER

andy1
Star Collaborator
Star Collaborator

Hi

The only way you can do that today is with the public API in 5.2.1. This should count the number of titles for each doc.

{
  "query": {
    "query": "name:*"
  },
  "facetFields": {
      "facets": [
         {"field": "DBID", "label": "DBID"}
      ]
    },
  "stats": [{
   "field" : "title",
   "label" : "Title"
  }],
    "pivots" : [
        {
            "key": "DBID",
            "pivots": [
                {
                    "key": "Title"
                }
                ]
        }
        ]
}

It does not have a way to get rid of counts you do not want.

In earlier versions you could go direct to SOLR and use the JSON facet API where you can expose what would normally be the "having" clause on the aggregate.

It will be a a bit of a pain as you will have to pick the correct field from the real solr schema.

Andy

View answer in original post

7 REPLIES 7

afaust
Legendary Innovator
Legendary Innovator

There is no query variant via default Alfresco Java APIs or any of the search languages for this particular use case.

xkahn
Champ in-the-making
Champ in-the-making

I suspect you are right. I'd be happy to use Solr directly if it supported the query.

I guess the best solution is to find all the documents with the property set at all... And then iterate through the results to find the documents I need.

resplin
Elite Collaborator
Elite Collaborator

Axel Faust‌ is usually correct about these things. I will ask around to see if we have a recommendation for this query.

It would help me to better understand the context around this requirement. What causes you to need to do this?

xkahn
Champ in-the-making
Champ in-the-making

Yeah. I'm trying to align the metadata in two different repositories. This property is split in the other repo. (Singleton value property and then multivariate property if more than one value is needed.) I wanted to see how much work this was going to be.

andy1
Star Collaborator
Star Collaborator

Hi

The only way you can do that today is with the public API in 5.2.1. This should count the number of titles for each doc.

{
  "query": {
    "query": "name:*"
  },
  "facetFields": {
      "facets": [
         {"field": "DBID", "label": "DBID"}
      ]
    },
  "stats": [{
   "field" : "title",
   "label" : "Title"
  }],
    "pivots" : [
        {
            "key": "DBID",
            "pivots": [
                {
                    "key": "Title"
                }
                ]
        }
        ]
}

It does not have a way to get rid of counts you do not want.

In earlier versions you could go direct to SOLR and use the JSON facet API where you can expose what would normally be the "having" clause on the aggregate.

It will be a a bit of a pain as you will have to pick the correct field from the real solr schema.

Andy

afaust
Legendary Innovator
Legendary Innovator

Well, if you can do that with the public API you should be able to do it with the Java API as well, right?

andy1
Star Collaborator
Star Collaborator

Hi


Yes, you can do it in the Java API as that is how we implement the public API - but again only on 5.2.1.

In general the public API is cleaner. The Java API has a couple of oddities for things like multi-select facets - but these do not matter for this case.
They were a pain to do in a backwards compatible way with the Java API.

Andy