On Sat, Nov 22, 2008 at 3:10 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : > it might be worth considering a new @attribute for <fields> to indicate > : > that they are going to be used purely as "component" fields (ie: your > : > first-name/last-name example) and then have DIH pass all non-component > : > fields along and error if undefined in the schema just like other updating > : > RequestHandlers do. > : > > : > either that, or require that people declaure indexed="false" > : > stored="false" fields in the schema for these intermediate component > : > fields so that we can properly warn then when DIH is getting data it > : > doesn't know what to do with -- protecting people from field name typos > : > and returning errors instead of silently ignoring unexpected input is > : > fairly important behavir -- especially for new users. > > : Actually it is done by DIH . When the dataconfig is loaded DIH reports > : these information on the console. though it is limited , it helps to a > : certain extent > > Hmmm. > > Logging an error and returning successfully (without adding any docs) is > still inconsistent with the way all other RequestHandlers work: fail the > request. > > I know DIH isn't a typical RequestHandler, but some things (like failing > on failure) seem like they should be a given. SOLR-842 . DIH is an ETL tool pretending to be a RequestHandler. Originally it was built to run outside of Solr using SolrJ. For better integration and ease of use we changed it later.
SOLR-853 aims to achieve the oroginal goal The goal of DIH is to become a full featured ETL tool. > > > > -Hoss > > -- --Noble Paul