So I'm using xc_solr, xc_metadata amongst others and I've successfully harvested in some content from external repositories. For each record, a 'Dublin Core' node has been created, and I can see the default layout when viewing the node. I can also see the records in Apache Solr. So far so good.
I then wanted to change the layout of the full node page and created a template for the Dublin Core full display. However, the node then appeared blank. That's when I noticed that they didn't appear in teaser listings either and no node title was displayed. I tracked the problem down to xc_metadata_view(). If we're displaying a teaser, or using a template for a full node, it calls xc_search_do_solr_search() with a solr query like "id:". $entity->identifier. The problem is Apache Solr isn't returning any data for that query and I end up with a blank node.
Now, I'm thinking that there is something wrong with my Apache Solr instance as querying it directly at http://www.example.com/solr/select?q=nid:123 or similar returns no records even though I can find that record if I just search for a word in the default field and the nid and id fields are configured to be indexed and stored. Don't suppose you've any idea why this isn't working? I'm using the xml files as provided by the apachesolr module.
However, I'm also wondering why does xc_metadata_view() connect to Apache Solr in the first place? Why does it not just use $entity->metadata like the full node display does when no template exists? Or if there is a reason for querying solr, why not default back to $entity->metadata if no response received or no record found in Solr?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 1018470.patch | 6.55 KB | stella |
Comments
Comment #1
stella commentedI found that by using the syntax http://www.example.com/solr/select?q={!field f=nid}123 the records are returned. I've patched the module to use this alternative syntax instead and my display templates are now being used. I changed all instances of the other syntax to this one, but haven't been able to test to confirm that it all works. In particular I would have liked to have been able to test the ones in xc_search.module like
$query = 'id:("' . join('" OR "', $xc_record['xc:workExpressed']) . '")';with the new syntax (which doesn't seem to support wrapping double quotes), but in any case the old syntax just doesn't work for me.The attached patch also changes the queries in hook_view to query on the node id rather than the entity identifier as the value in
$entity->identifier(e.g. oai:myrepos.com:15407) doesn't match the value stored in that Solr field e.g. rt00jf/node/192 (where rt00jf is the hash value btw).Comment #2
pkiraly commentedHi Stella,
now we are working hard on finalizing our demo site, and a new release, but as soon as I can I will try your patch (I hope later this week). I'd like to assure you, that your comments are extremely important, but this time I can't you answer the way I's like to. You are right, that that part of xc_metadata_view() is far from optimal solution, and it is important to change. The OAI IDs may contain some characters which should be escaped in Solr, so it is advisable to use phrase search. Though I don't understand why the standard Solr query format is not working for you. Without further investigation I can not apply this path. Could you send me an example ID? (not like "123", but one which contains all character types of a real ID in case you don't want to send us a real ID).
Thanks!
Péter
Comment #3
pkiraly commentedOne more question: which Solr version do you use?
Comment #4
stella commented@pkiraly - thanks. An anonymised $entity->identifier is "oai:myrepos.com:15407" but as I said earlier in the record it should match, the id is "rt00jf/node/192". I'm running apache-solr-1.4.1
Comment #5
pkiraly commentedI'd like to recheck, that you the following query is not working for you: http://www.example.com/solr/select?q=id:"oai:myrepos.com:15407" (with double quotes, and using Solr directly).
Comment #6
stella commentedNo, that query is not working for me. Neither is http://www.example.com/solr/select?q=nid:"192" but http://www.example.com/solr/select?q={!field f=nid}192 does and similarly with the id, and other fields.
I'm still having problems with the display templates by the way - different issue though, as a record is now being returned at least. I'll open a separate ticket for it though.
Comment #7
pkiraly commentedI have think about this problem, but I can't find what is wrong with your Solr. We use different Solr versions, and I haven't ran into the same problem. The Solr API (http://lucene.apache.org/solr/api/org/apache/solr/search/FieldQParserPlu...) said, that {!field f=myfield}Foo Bar is equivalent with myfield:"Foo Bar". In the wiki I haven't find examples. Could you point me a description of it? We provided a solrconfig.xml, do you use that? Or do you use different config other than the standard?
From the information I collected so far the syntax change in the module is not necessary, and it is definitely would involve a lots of work. I can imagine, that we can create somewhere a configuration where the administrator can change to the new syntax.