Hi Rafa, When you used solrQuery parameter, it is directly passed to the solr. Thus, if you use [1], only documents will be returned, if you want to the facets in response you should use a query like [2]. Before the commit, all available facets are added to the solrQuery by default, and with [1], all facets are returned in response which is actually wrong.
If you use queryTerm[3], this time queryTerm is converted to the SolrQuery, and all the facets must be added to this query, then passed to the solr, so you can see all available facets in the response. However, due to the fix in SolrQuery part, all facets are not added to the query before passing to the solr. Hence, empty facet list is returned in response. I fixed it and queries in the below worked as expected in my launcher. Let me know if still something is wrong. Best, Meriç [1] http://localhost:8080/contenthub/contenthub/search/featured?solrQuery=q=paris [2] http://localhost:8080/contenthub/contenthub/search/featured?solrQuery=q=paris%26facet=true%26facet.field=places_t [3] http://localhost:8080/contenthub/contenthub/search/featured?queryTerm=paris 2013/2/27 Rafa Haro <[email protected]> > Hi Meric, > > I have done a clean installation of Stanbol from svn HEAD revision and now > FeaturedSearch seems not to be working at all. I can't get any facet in the > JSON response neither in ContentHub Search UI at http://localhost:8080/** > contenthub/contenthub/search/**featured<http://localhost:8080/contenthub/contenthub/search/featured>where > the facets div in the HTML response of the service is empty. I have > checked if the ContentItem has been correctly indexed in Solr and it has > been stored without problems with all the semantic fields. > > No errors in the log also. > > Any idea? > > > El 26/02/13 10:19, Meriç Taze escribió: > >> Hi Rafa, >> >> >> There was a problem with the conversion of the string to actual SolrQuery. >> I have fixed and committed it. Here is an example usage that I have tried, >> >> curl -i " >>> >> http://localhost:8080/**contenthub/contenthub/search/** >> featured?solrQuery=q=paris%**26facet=true%26facet.field=**places_t<http://localhost:8080/contenthub/contenthub/search/featured?solrQuery=q=paris%26facet=true%26facet.field=places_t> >> " >> >> HTTP/1.1 200 OK >> Content-Type: application/json; charset=utf-8 >> Content-Length: 612 >> Server: Jetty(6.1.x) >> { >> "documents": [{ >> "localid": >> "urn:content-item-sha1-**d8cb233824c493e80d744a8120469e**40be97444d", >> "mimetype": "text\/plain", >> "title": "paris", >> "enhancementcount": 4 >> }], >> "facets": [{ >> "facet": { >> "name": "places_t", >> "values": [ >> { >> "name": "Paris", >> "count": 1 >> }, >> { >> "name": "Paris, Texas", >> "count": 1 >> } >> ] >> }, >> "type": "string" >> }], >> "relatedkeywords": [{"paris": []}] >> } >> >> >> Thanks for reporting. >> Best, >> Meriç >> >> 2013/2/19 Rafa Haro <[email protected]> >> >> Hi, >>> >>> I just wanted to share with the list an issue that I have faced working >>> with FeaturedSearch REST service within ContentHub. I have been >>> developing >>> a Java Client for ContentHub services and I think that FeaturedSearch >>> RESTful API documentation should be clarified. Specifically, one of the >>> request parameters is a Solr query String. According to the >>> documentation, >>> this parameter is " /the string format which is accepted by a Solr >>> server. >>> For example, q="john doe"&fl=score" >>> >>> /The format of the example query is consistent with the String that you >>> get with SolrQuery.getQuery method in Solrj library and it's also >>> consistent with a Solr GET request URL query. The problem is that this >>> string seems not to be consistent with SolrQuerySintax [1], so, it is >>> not a >>> valid String query for building a SolrQuery from the raw String with >>> Solrj. >>> Correct me if I'm wrong, but I think that FeaturedSearch implementation >>> is >>> directly building a SolrQuery from the solrQuery String parameter of the >>> service. >>> >>> I have done several tests with queries similar to the example query and I >>> never get the correct results. I also try to build SolrQuery queries with >>> Solrj programmatically and then pass SolrQuery.getQuery String as the >>> parameter of the service without success. In fact, I haven't been able to >>> find a way to convert a Solrj SolrQuery object to a well formed Solr >>> String. >>> >>> Using a raw String consistent with SolrQuerySintax and passing it as the >>> solrQuery parameter is the only way I have find to get the correct >>> results. >>> >>> I think that this issue is not a bug, but the documentation leads you to >>> think that you can use Solr URL like queries strings and, at least for >>> me, >>> that's not working. >>> >>> [1] >>> http://wiki.apache.org/solr/****SolrQuerySyntax<http://wiki.apache.org/solr/**SolrQuerySyntax> >>> <http://wiki.**apache.org/solr/**SolrQuerySyntax<http://wiki.apache.org/solr/SolrQuerySyntax> >>> > >>> >>> >>> Regards >>> / >>> / >>> >>> -- >>> >>> ------------------------------ >>> This message should be regarded as confidential. If you have received >>> this >>> email in error please notify the sender and destroy it immediately. >>> Statements of intent shall only become binding when confirmed in hard >>> copy >>> by an authorised signatory. >>> >>> Zaizi Ltd is registered in England and Wales with the registration number >>> 6440931. The Registered Office is 222 Westbourne Studios, 242 Acklam >>> Road, >>> London W10 5JJ, UK. >>> >>> > > -- > > ------------------------------ > This message should be regarded as confidential. If you have received this > email in error please notify the sender and destroy it immediately. > Statements of intent shall only become binding when confirmed in hard copy > by an authorised signatory. > > Zaizi Ltd is registered in England and Wales with the registration number > 6440931. The Registered Office is 222 Westbourne Studios, 242 Acklam Road, > London W10 5JJ, UK. >
