On Fri, Jul 10, 2009 at 2:02 PM, solrcoder <solrco...@gmail.com> wrote:
> > > markrmiller wrote: > > > > Coming soon. First step was here: > > http://issues.apache.org/jira/browse/LUCENE-1699 > > Trunk doesn't have that version of Lucene yet though (I believe thats > > still > > the case). > > > > Replacing the RunUpdateProcessor give you full control of the Lucene > > document creation. > > > > Is "replacing the RunUpdateProcessor" something *I* would do with a custom > subclass, or something that the devs are merging into trunk? I couldn't > find many docs about it on the web. When you specify a custom UpdateProcessor chain, you will normally make the RunUpdateProcessor the last processor in the chain, as it will add the doc to Solr. Rather than using the built in RunUpdateProcessor though, you could simply specify your own UpdateProcessor as the last one. Take a look at the RunUpdateProcessor code - its pretty simple. On update it does: @Override public void processAdd(AddUpdateCommand cmd) throws IOException { cmd.doc = DocumentBuilder.toDocument(cmd.getSolrInputDocument(), req.getSchema()); updateHandler.addDoc(cmd); super.processAdd(cmd); } That is where the Lucene Document is created, and so you can use this plugin hook (a custom update chain) to create it however you want (though you obviously need to model what you do on DocumentBuilder.toDocument). > > > Also, any idea if "soon" means in the Solr 1.4 release? Dunno - but I think so. If all it needs is the Lucene update, than def - and I think you can prob do it with just that. But there may still be a gotchya to resolve on the Solr end - I'm not 100% at the moment. > > > Thanks for the heads up! > -- > View this message in context: > http://www.nabble.com/Modifying-a-stored-field-after-analyzing-it--tp24426623p24428208.html > Sent from the Solr - User mailing list archive at Nabble.com. > > -- -- - Mark http://www.lucidimagination.com
