[
https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271273#comment-13271273
]
Per Steffensen commented on SOLR-3178:
--------------------------------------
Sorry to see that you chose to commit a different patch for this one, making me
believe that you are not going to take my patch in. I really dont understand
why, because I think my solution is at least as good or better in any aspect,
and besides that it is more complete, backward compatible and solves a lot of
other issues (SOLR-3173, SOLR-3382 and SOLR-3428) already - can I ask you to
tell me why you made that choice? Maybe what is wrong with our patch since it
is not taken in, what we need to change etc?
Please also elaborate on your plans wrt the other issues
* Using unique key constraints to protect against overwriting existing data,
when intent is to just insert a new document (kinda what SORL-3173 was thought
to be about) - DocumentAlreadyExists error
* Even though an document update fails, still try updating the rest of the
documents in the same update request, and therefore the feature of being able
to report several errors back to the client linking each error to a specific
document in the request (basically SOLR-3382)
* Nicely "typed" errors so that you as a client can detect which kind of error
occurred in an easier way than guessing from http status code and textual error
messages (also SOLR-3382)
* The SOLR-3428 bug
I need to know what to tell my product owners wrt how long we need to run on
our own version of Solr (containing our patches etc.) in our high-throughput
and high-concurrency pilot-prod system and therefore also for how long we need
to keep merging changes from Solr trunk in? And when we can get to contribute
additional code - mostly stability/endurance-related bug fixes. We already gave
you the fix for SOLR-3437 but some of our additional fixes are kinda dependent
on some of the stuff in SOLR-3173_3178_3382_3428_plus.patch. Do you have any
plans revealing if we have to wait
* Forever? (= our patch is not going to be committed)
* Weeks/Days? (= you are working on understanding our patch and expect to
commit later)
* Or?
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: [email protected]
For additional commands, e-mail: [email protected]
