Hi Meriç,
I have been doing some tests and I think that I understand now how your
changes have affected to FeaturedSearch service functionality. I had a
list of tests based on previous versions and most of them didn't work
after your last changes. I agree with you that maybe it was wrong to get
all the facets just using a queryTerm, but I still see it very useful
(although is just a personal opinion).
Also, I was confused about constraints parameter after your changes. I
have seen in the code that now the constraints parameter is being used
only when you perform a search using queryTerm parameter and not
solrQuery. I think that currently, it might doesn't make sense to use
constraints in that way. I have always thought that the constraints
parameter was an easy way to refine the user search using the facets.
When the user click on a facet value, you just add the new constraint to
the previous search. IMO that doesn't make sense any more, because you
now can apply constraints with queryTerms but you can't get facets at
the same time and, on the other hand, constraints parameter is not being
used when you pass a solrQuery instead of a queryTerm.
Therefore, in summary, it seems that now, to refine an user search
through the facets, you need to refine the SolrQuery because is the only
way to still getting facets. Maybe I'm wrong but I think that makes the
constraints parameter unnecessary.
All the best,
Rafa
El 27/02/13 21:49, Meriç Taze escribió:
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.
--
------------------------------
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.
