lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3173) Database semantics - insert and update
Date Wed, 29 Feb 2012 13:07:57 GMT

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

Yonik Seeley commented on SOLR-3173:
------------------------------------

bq. I belive you are already commenting on the related Jira issue that I havnt created yet

Optimistic locking as a superset to insert/update:

What I already had in mind:
- update only a specific version of the document by specifying it's exact version:  _version_=12345
- add a document only if it doesn't already exist (i.e. insert): _version_=-1
- add a document regardless: don't specify a version

So now that I look at it again, it looks like what's missing is your "UPDATE" semantics which
would only replace the record if it already existed (a weaker form of the first case... any
positive version is OK).  But I really wonder how useful those semantics are (only add a doc
if it's overwriting an existing doc, regardless of what version or what data it contains?)

If there are usecases, we certainly should be able to do it.

As far as what \_version\_ is, it's new and used for solrcloud to handle reorders of updates
to replicas (among other things).
The leader shard decides what the version of a document should be (versions only increase),
and forwards the doc with the version to the replicas.
If a replica receives the same doc with a lower version, it knows that it can safely drop
it because it already has a newer version.


                
> Database semantics - insert and update
> --------------------------------------
>
>                 Key: SOLR-3173
>                 URL: https://issues.apache.org/jira/browse/SOLR-3173
>             Project: Solr
>          Issue Type: New Feature
>          Components: update
>    Affects Versions: 3.5
>         Environment: All
>            Reporter: Per Steffensen
>            Assignee: Per Steffensen
>              Labels: RDBMS, insert, nosql, uniqueKey, update
>             Fix For: 4.0
>
>   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 the following features inspired by RDBMSs and other NoSql databases.
> * Given a solr-core with a schema containing a uniqueKey-field "uniqueField" and a document
Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField,
then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed
into the solr-core.
> * Given a solr-core with a schema containing a uniqueKey-field "uniqueField" and a document
Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField
I want Dold deleted from and Dnew added to the index (just as it is today).If no such document
Dold exists I want nothing to happen (Dnew is not added to the index)
> The essence of this issue is to be able to state your intent (insert or update) and have
slightly different semantics (from each other and the existing update) depending on you intent.
> 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-3178, 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