lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-3178) Versioning - optimistic locking
Date Tue, 24 Apr 2012 18:39:34 GMT

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

Per Steffensen edited comment on SOLR-3178 at 4/24/12 6:38 PM:
---------------------------------------------------------------

Find attached SOLR_3173_3178_3382_plus.patch which should fit on top of revision 1327417.

Patch includes:
- All our code-changes done during the work with SOLR-3173, SOLR-3178 and SOLR-3382. How it
is supposed to work in more detail, is described on http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics
and is of course also expressed in included tests.
- Also includes
-- Misc clean-up 
--- E.g. removing constants redundant OVERWRITE = "overwrite" so that only UpdateParams.OVERWRITE
is left. You need very good arguments to ever use different "names" for the same thing (overwrite)
among XML, JSON, HTTP request params etc, so it is kind of wrong to have the constant defined
for each of those.
-- "Unimportant changes" - e.g.
--- Corrected spelling errors
--- Removed unnecessary imports

Not implemented yet
- Error propagation for redistributed updates. That is, the responses from the redistributed
updates in DistributedUpdateProcessor using SolrCmdDistributor, have to be collected an merged
into a combined response from "this" DistributedUpdateProcessor.
-- Both implementation and tests are missing.
- Tests verifying that updates using JSON and CSV requests as described on http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics
also works as described. Especially transfer of partRefs in JSON and CSV requests.
- Tests verifying that semanticsMode "consistency" works as it is supposed to - just like
ClassicConsistencyHybridXXXTests tests this for "classic-consistency-hybrid" semanticsMode
and like ClassicUpdateSemanticsTest shortly tests it when semanticsMode is explicitly set
to "classic" ("classic" is the default so this mode is already tested a lot using all the
others tests in the project)

Other stuff not done yet
- Add Apache 2.0 Licence to all new files
- Check correct indenting
- JavaDoc for public methods
                
      was (Author: steff1193):
    Find attached SOLR_3173_3178_3382_plus.patch which should fit on top of revision 1327417.

Patch includes:
- All our code-changes done during the work with SOLR-3173, SOLR-3178 and SOLR-3382. How it
is supposed to work in more detail, is described on http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics
and is of course also expressed in included tests.
- Also includes
-- Misc clean-up 
--- E.g. removing constants redundant OVERWRITE = "overwrite" so that only UpdateParams.OVERWRITE
is left. You need very good arguments to ever use different "names" for the same thing (overwrite)
among XML, JSON, HTTP request params etc, so it is kind of wrong to have the constant defined
for each of those.
-- "Unimportant changes" - e.g.
--- Corrected spelling errors
--- Removed unnecessary imports

Not implemented yet
- Error propagation for redistributed updates. That is, the responses from the redistributed
updates in DistributedUpdateProcessor using SolrCmdDistributor, have to be collected an merged
into a combined response from "this" DistributedUpdateProcessor.
-- Both implementation and tests are missing.
- Tests verifying that updates using JSON and CSV requests as described on http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics
also works as described. Especially transfer of partRefs in JSON and CSV requests.
- Tests verifying that semanticsMode "consistency" works as it is supposed to - just like
ClassicConsistencyHybridXXXTests tests this for "classic-consistency-hybrid" semanticsMode
and like ClassicUpdateSemanticsTest shortly tests it when semanticsMode is explicitly set
to "classic" ("classic" is the default so this mode is already tested a lot using all the
others tests in the project)

Other stuff not done yet
- Add Apache 2.0 Licence to all new files
- Check correct indenting
                  
> 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-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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message