On 8/5/2013 3:02 AM, Christian Köhler - ZFMK wrote: >> to have a database table holding the relationships between countries and >> continents, and using a join to get the continent. > > I forgot to mention: I only have reading access to the database.
Somebody's got to write something. If you don't have write access to the data, here are some things the DB admin could do: 1) Add a field to the table for the continent. Write a program that goes through the records, figures out the continent, and populates that field for every row. This would cause at least a little bit of DB downtime. 2) Set up the table that Raymond recommended, so you can do a JOIN in your SELECT statement. 3) Use DB server-side code (perhaps a stored procedure?) and give you a database view that uses that code to add a continent field to the results. It would be very good to have data like the continent in your source database. If the DB admin can't or won't do any of these things, then you'd have to do it yourself. This likely means one of two things: 1) Write an application to read the data from the database and index the data to Solr. In terms of Solr functionality, the Java API (SolrJ) is the most comprehensive. This would basically be a rewrite of the DataImport handler, but unless it's multi-threaded and written very carefully, it probably won't be as efficient as DIH. 2) Write a custom UpdateProcessor for the Solr server side that does the mapping, and continue using Solr's DataImport handler. Thanks, Shawn
