The DIH is strictly tree-structured. Data flows down the tree. If the first sibling is the root entity, nothing is used from the second sibling. This configuration is something that it the DIH should fail.
On Thu, Mar 10, 2011 at 9:14 AM, Chantal Ackermann <chantal.ackerm...@btelligent.de> wrote: > Hi Gora, > > thanks for making me read this part of the documentation again! > This processor probably cannot do what I need out of the box but I will > try to extend it to allow specifying a regular expression in its "where" > attribute. > > Thanks! > Chantal > > On Thu, 2011-03-10 at 17:39 +0100, Gora Mohanty wrote: >> On Thu, Mar 10, 2011 at 8:42 PM, Chantal Ackermann >> <chantal.ackerm...@btelligent.de> wrote: >> [...] >> > Is this supposed to work at all? I haven't found anything so far on the >> > net but I could have used the wrong keywords for searching, of course. >> > >> > As answer to the maybe obvious question why I'm not using a subentity: >> > I thought that this solution might be faster because it iterates over >> > the second data source instead of hitting it with a query per each >> > document. >> [...] >> >> I think that what you are after can be handled by Solr's >> CachedSqlEntityProcessor: >> http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor >> >> Two major caveats here: >> * I am not 100% sure that I have understood your requirements. >> * The documentation for CachedSqlEntityProcessor needs to be improved. >> Will see if I can test it, and come up with a better example. As I have >> not actually used this, it could be that I have misunderstood its purpose. >> >> Regards, >> Gora > > -- Lance Norskog goks...@gmail.com
