[
https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291668#comment-13291668
]
Per Steffensen edited comment on SOLR-3178 at 6/8/12 11:13 AM:
---------------------------------------------------------------
{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
http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics#Multi_document_updates
{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 (in order to be
able to "trust the test suite" will reveal if future commits will ruin this new
feature)
* 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
was (Author: steff1193):
{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
http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics#Multi_document_updates
{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: https://issues.apache.org/jira/browse/SOLR-3178
> 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 handling.
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
