On Mon, 2007-01-15 at 12:23 -0800, Chris Hostetter wrote: > : > Right, you're getting at issues of why I haven't committed my CSV handler > yet. > : > It currently handles reading a local file (this is more like an SQL > : > update handler... only a reference to the data is passed). But I also > : > wanted to be able to handle a POST of the data , or even a file > : > upload from a browser. Then I realized that this should be generic... > : > the same should also apply to XML updates, and potential future update > : > formats like JSON. > : > : I do not see the problem here. One just need to add a couple of lines in > : the upload servlet and change the csv plugin to input stream (not local > : file). > > what Yonik and i are worried about is that we don't want the list of all > possible ways for an Update Plugin to get a Stream to be hardcoded in the > UpdateServlet or Solr Core or in the Plugins themselves ... we'd like the > notion of indexing docs expressed as CSV records or XML records or JSON > records to be independent of where the CSV, XML, or JSON data stream came > from ... in the same way that the current RequestHandlers can execute > specific search logic, without needing to worry about what format the > results are going to be returned in. > > > It's not writting code to get the stream from one of N known ways > that's hard -- it's designing an API so we can get the stream from one of > any number of *unknown* ways that can be specified at run time thats > tricky :) >
Ok, I am still trying to understand your concept of micro-plugin, but I understand the above and your comments later in this thread that you are looking for a generic stream resolver/producer (or solrSource). On Mon, 2007-01-15 at 12:42 -0800, Chris Hostetter wrote: > i disagree ... it should be possible to create "micro-plugins" (I > think i > called them "UpdateSource" instances in my orriginal suggestion) that > know > about getting streams in various ways, but don't care what format of > data > is found on those streams -- that would be left for the > (Update)RequestHandler (which wouldn't need to know where the data > came > from) > > a JDBC/SQL updater would probably be a very special case -- where the > format and the stream are inheriently related -- in which case a No-Op > UpdateSource could be used that didn't provide any stream, and the > JdbcUpdateRequestHandler would manage it's JDBC streams directly. So to understand better: user request -> micro-plugin -> RequestHandler -> ResponseHandler Right? salu2
