On 1/12/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
For now, it extends SolrRequestHandler (not UpdateHandler) because the request plugin framework seems more stable.
There is no framework for pluggable update handlers yet... Solr's current UpdateHandler classes (DirectUpdateHandler2) are a bit misnamed in this context... they deal with the low-level lucene index munging and concurrency issues, more like an IndexWriter.
What is the best way to post unfinished code and ask for review? Should i make a JIRA issue and post a patch with a "not ready for prime time" note? Should I post the code on a personal website?
Yep, and adding a note that it's just a draft is important.
Does this belong in the main package o.a.s.update?
IMO, yes (or in o.a.s.update.db or sql). SQL databases are ubiquitous, and we don't want everyone having to do the same integration steps themselves to index their db content.
or a 'contrib' package/project/source folder? If it is in the main tree: the unit tests require mysql-connector.jar and assume you have a database at: jdbc:mysql://localhost/solrtestsql with user=solr and password=solr. Any suggestions on how this should be handled or structured.
I'm split on this one... It seems like it would be nice if we didn't have any vendor specific db stuff in the core or in the repository. On the other hand, if the vast majority of people will be using this with mysql, why make them go through the trouble. -Yonik
