Previously, in Part 1 of this series, I blogged about some difficulties in working with Solr. I am following up with some more lessons learned.
- In order to index with more than one category, Adobe suggested that instead of category=”column1,column2″, which places the literal value “column1,column2″ in the category instead of getting the respective values, I try: category=”#queryName.column1#,#queryName.column2#”. When I did this, it transformed the values all right, but of the first record only. So all records in the index has the same value of the first record. My hack?
- Run the query as usual.
- Do a query of query. Do: SELECT *, column1 + ‘,’ + column2 AS indexCategory FROM queryName.
- Instead of category=”column1,column2″, use category=”indexCategory”. This will put the appropriate comma-delimited category in place.
- Basically since cfindex will work correctly with a single category, I cfquery to create a special column for this of containing the values I wanted.
- Escape Special Characters. One of the categories I was using was a lookup of state codes. So it has values like CA, VA, NY, and OR. Notice something odd? That’s right, Solr didn’t like ‘OR’, since it is a reserved operator word. In fact, you can go here to see a list of reserved words and a notice on escaping characters for Lucene and Solr @ http://lucene.apache.org/java/2_4_0/queryparsersyntax.html#Escaping%20Special%20Characters. NOTE: This escaping was needed only when searching using CFSearch, not when indexing. Maybe someone should make a UDF for this, but my simple fix was: replace(VALUE,’OR’,’OR’). Note the .
- More to come…