Personally, I just create a view that flattens out the database and renames the fields as I desire. Then I call the view with the DIH to import it.
Solr doesn't knwo anything about the databsae, except how to get a connection and fetch rows. And that's pretty darn useful, just that much less code to write. Dennis Gearon Signature Warning ---------------- It is always a good idea to learn from your own mistakes. It is usually a better idea to learn from others’ mistakes, so you do not have to make them yourself. from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036' EARTH has a Right To Life, otherwise we all die. ----- Original Message ---- From: Upayavira <u...@odoko.co.uk> To: solr-user@lucene.apache.org Sent: Fri, January 28, 2011 1:41:42 AM Subject: Re: Solr for noSQL On Thu, 27 Jan 2011 21:38 -0800, "Dennis Gearon" <gear...@sbcglobal.net> wrote: > Why not make one's own DIH handler, Lance? Personally, I don't like that approach. Solr is best related to as something of a black box that you configure, then push content to. Having Solr know about your data sources, and pull content in seems to me to be mixing concerns. I relate to the DIH as a useful tool for smaller sites or for prototyping, but would expect anything more substantial to require an indexing application that gives you full control over the indexing process. It could be a lightweight app that uses a MongoDB java client and SolrJ, and simply pulls from one and pushes to the other. If you don't want to run another JVM, it could run as a separate webapp within your Solr JVM. From an architectural point of view, do you configure Mysql, or MongoDB for that matter, to pull content into itself? Likewise, Solr should be a service that listens, waiting to be given data. Upayavira --- Enterprise Search Consultant at Sourcesense UK, Making Sense of Open Source
