lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2193) Re-architect Update Handler
Date Wed, 01 Jun 2011 03:56:47 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041974#comment-13041974
] 

Shai Erera commented on SOLR-2193:
----------------------------------

bq. The concept of Solr continuing to be difficult to customize is not so great. 

I haven't looked at the patch at all, as I'm not familiar w/ Solr code and cannot comment
on the technical issues here. But I do would like to understand if this patch indeed gets
us further from being able to customize Solr in the future or not.

By customizing I mean (and I realize not all of it is handled in this issue):
# Control the IW instance through not only properties, but IW extensions (for e.g. overriding
addDocument / commit so that other custom data structures can be updated at the same time
as well).
# Control the replication process, for e.g., replicating additional files, not only IW files,
that are required by the runtime logic.
# Control the IndexSearcher instance, or the query execution engine, in order to run queries
at the low-level. i.e., being able to call IS.search(Q, Collector), and not from some high-level
API where I can only submit a String and get back Result.

These are important extension points, IMO, to Solr that we can offer applications. I admit,
really advanced applications that know what they do and want, that just don't want to rewrite
Solr entirely in order to execute queries differently.

NOTE: I am not trying, nor do I want, to discuss here whether it should be the roadmap of
Solr (i.e., provide all sorts of extensions that enable the above), but merely asking if that
patch indeed gets us further from accomplishing that. I will not cast any +/-1 vote if it
does, just (being a Solr dummy, not even "at best") trying to understand if that's really
what's being proposed here.

> Re-architect Update Handler
> ---------------------------
>
>                 Key: SOLR-2193
>                 URL: https://issues.apache.org/jira/browse/SOLR-2193
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Mark Miller
>             Fix For: 4.0
>
>         Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch
>
>
> The update handler needs an overhaul.
> A few goals I think we might want to look at:
> 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler,
DefaultUpdateHandler
> 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what
we now do with special casing:
> if (directupdatehandler2)
>   success
>  else
>   failish
> 3. Stop closing the IndexWriter and start using commit (still lazy IW init though).
> 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level.
> 5. Keep NRT support in mind.
> 6. Keep microsharding in mind (maintain logical index as multiple physical indexes)
> 7. Address the current issues we face because multiple original/'reloaded' cores can
have a different IndexWriter on the same index.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message