lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <>
Subject [jira] [Commented] (SOLR-3178) Versioning - optimistic locking
Date Fri, 08 Jun 2012 10:20:23 GMT


Per Steffensen commented on SOLR-3178:

{quote} Regarding error handling, I tracked down the original issue: SOLR-445 {quote}

Yes, SOLR-445 is solved by my patch - the nice way. On certain kinds of errors (PartialError
subclasses) during the handling of a particular document in a nultidocument/batch-update the
processing of subsequent documents will continue. The client will receive a response describing
all errors (wrapped in PartialErrors) that happend during the processing of the entire update-request
(multidocument/batch). Please have a look at

{quote} It's just a guess, but I think it unlikely any committers would feel comfortable tackling
this big patch, or even have time to understand all of the different aspects. They may agree
with some parts but disagree with other parts {quote}

Of course that is up to you, but I believe Solr has a problem being a real Open Source project
receiving contributions from many semi-related organistions around the world, if you do not
"trust your test suite". Basically when taking in a patch a committer do not need to understand
everything down to every detail. It should be enough (if you "trust your test suite") to
* Verify that all existing tests are still green - and havnt been hacked
* Verify that all new tests seem to be meaningfull and covering the features described in
the corresponding Jira (and in my case the associated Wiki page), indicating that the new
features are usefull and well tested
* Scan through the new code to see if it is breaking any design principals etc., and in general
if it seems to be doing the right thing the right way

As long as a patch does not break any existing functionality, and seems to bring nice new
functionality (you should be able to see that from the added tests) a patch cannot be that
harmfull - you can always refactor if you realize that you "disagree with some parts". It
all depends on "trusting your test suite". Dont you agree, in principle at least?

Regards, Per Steffensen

> Versioning - optimistic locking
> -------------------------------
>                 Key: SOLR-3178
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: update
>    Affects Versions: 3.5
>         Environment: All
>            Reporter: Per Steffensen
>            Assignee: Per Steffensen
>              Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning
>             Fix For: 4.0
>         Attachments: SOLR-3173_3178_3382_3428_plus.patch, SOLR-3178.patch, SOLR_3173_3178_3382_plus.patch
>   Original Estimate: 168h
>  Remaining Estimate: 168h
> In order increase the ability of Solr to be used as a NoSql database (lots of concurrent
inserts, updates, deletes and queries in the entire lifetime of the index) instead of just
a search index (first: everything indexed (in one thread), after: only queries), I would like
Solr to support versioning to be used for optimistic locking.
> When my intent (see SOLR-3173) is to update an existing document, I will need to provide
a version-number equal to "the version number I got when I fetched the existing document for
update" plus one. If this provided version-number does not correspond to "the newest version-number
of that document at the time of update" plus one, I will get a VersionConflict error. If it
does correspond the document will be updated with the new one, so that "the newest version-number
of that document" is NOW one higher than before the update. Correct but efficient concurrency
> When my intent (see SOLR-3173) is to insert a new document, the version number provided
will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert
will only succeed if a document with the same value on uniqueKey-field does not already exist.
> In general when talking about different versions of "the same document", of course we
need to be able to identify when a document "is the same" - that, per definition, is when
the values of the uniqueKey-fields are equal. 
> The functionality provided by this issue is only really meaningfull when you run with
"updateLog" activated.
> This issue might be solved more or less at the same time as SOLR-3173, and only one single
SVN patch might be given to cover both issues.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message