| | 1 | = SOLR Interface = |
| | 2 | |
| | 3 | == Use Cases == |
| | 4 | As an admin of a CKAN instance I want to have the facility to use SOLR, both alongside and as a replacement for the existing full text search in CKAN. |
| | 5 | |
| | 6 | == Design == |
| | 7 | |
| | 8 | There are two main options for getting data into SOLR: |
| | 9 | |
| | 10 | * POST the records to SOLR in XML format ([http://wiki.apache.org/solr/UpdateXmlMessages docs]) |
| | 11 | * Direct connection Setup SOLR ([http://wiki.apache.org/solr/DataImportHandler docs]) |
| | 12 | * Provide SELECT statements to do queries |
| | 13 | * Process is initiated by doing a GET to a particular SOLR URL |
| | 14 | |
| | 15 | The preference is for the first option as the abstraction provides more flexibility in the db and more control about what gets indexed. |
| | 16 | |
| | 17 | == Tickets == |
| | 18 | |
| | 19 | * Get a SOLR instance running locally and/or eu1, using basic config. |
| | 20 | * Harness one of the three python SOLR libraries to send SOLR Update XML of CKAN Packages. |
| | 21 | * Write tests for SOLR by sending data with SOLR library and using JSON interface for queries. |
| | 22 | * Optimise the SOLR settings for searching our data well - fields description in schema.xml. (Link to schema.xml in developer docs.) |
| | 23 | * Provide option to connect CKAN's search WUI to SOLR back-end. |
