Lessons Learned: Moving from Verity to Solr (Part 2)

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?
  1. Run the query as usual.
  2. Do a query of query. Do: SELECT *, column1 + ‘,’ + column2 AS indexCategory FROM queryName.
  3. Instead of category=”column1,column2″, use category=”indexCategory”. This will put the appropriate comma-delimited category in place.
  4. 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…

Advertisement