Until recently, I always thought it was necessary to have Lucene on the local client, then along came Solr. Then I thought that having Solr embedded in the local client was necessary. Now, I'm not as sure.
A major use of Lucene/Solr in my application is as a dependancy injection system for many configurations that are encoded as JSON and then analysed and indexed as documents. Different application objects will look to document fields for their runtime parameters. At anytime a query can be made that loads in (activates) a different set of documents causing the objects to behave according to alternate parameters (rules). One of my main concerns has been the need for speed. The objects need to access the parameters they need in realtime. I have learnt that queries on an index will never be as fast as accessing a map in memory. This means I need to have my own memory structure that documents would be converted to. Toward this end there is the JSONObject from the org.json API that seems suitable for the task. If Solr is used on a remote server and returns document results in the JSON format then it is easy to build/deserialize JSONObjects from documents. The JSONObject is essentially a map in memory, providing fast access to the parameters objects require. Are there fast index solutions available? What about InstantiatedIndex, a Lucene contrib module? Maybe it is best to keep the client lightweight. It could be that Solr on a remote server is all I need and local access/parameter search can be done using maps? Any advice is appreciated, thanks. Thom --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
