[
https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266385#comment-13266385
]
Per Steffensen edited comment on SOLR-3178 at 5/2/12 6:39 AM:
--------------------------------------------------------------
bq. {quote} since I offer the "semanticsMode" property in updatehandler
{quote}
{quote} Seems like this should be up to the client... why wouldn't update
semantics be handled on a per-request basis? {quote}
Maybe we misunderstand each other a little bit. I just agree that people want
Solr to provide different kinds of semantics - some want strict version-check,
some dont, some will have an fire-and-forget approach, some will not. I just
ment to say that for some of those types of semantics you want server-side Solr
to behave in a certain way. For that you probably need a configuration telling
the server how to behave. I have introduced that for updates with the
"semanticsMode" config on updatehandler.
I believe, when it comes to whether you want strict unique-key-constraint- and
version-checks or not, it is probably something you want to configure
server-side, so that you can control the possibilities of your clients. Not all
Solr-based systems will have complete control over all its clients, and then it
is nice on server-side to be able to say (using semanticsMode):
* consistency: I dont want you as a client to make updates to documents,
without even having read the existing document first (and merged your updates
into that), and I dont want you to be able to overwrite changes to that
document that happend to be made between the time you read it and the time you
provided your updated version. And I dont want you to incidentally overwrite an
existing document, if your intent was to create a new one.
* classic: All updates just go right into Solr, but you risk overwriting
exsisting stuff
* classic-concistency-hybrid: You can do both consistency and classic updates,
be casefull when doing classic updates
I believe this kind of control belongs in a server-side config, because it is a
way of "protecting" your data against badly written clients.
With respect to whether you want to do fire-and-forget or not, that should be
up to the client, but it kinda is by definition - basically just ignore
results. But fire-and-forget strategy on clients is really not worth much, if
you have to wait for the server to reply when you do updates (like you have to
do today). SOLR-3383 will provide a all-async client SolrJ API (Future-based
all the way) so that you can really just "fire", and if you intent is to
"forget" anyway, then you can move on immediately after your "fire" without
waiting for the server to reply.
That is not the reason we made SOLR-3383 though. It is because we want to be
able to get results back when using ConcurrentSolrServer, and that requires a
Future-based request API.
Regards, Per Steffensen
was (Author: steff1193):
{quote} .bq since I offer the "semanticsMode" property in updatehandler
{quote}
{quote} Seems like this should be up to the client... why wouldn't update
semantics be handled on a per-request basis? {quote}
Maybe we misunderstand each other a little bit. I just agree that people want
Solr to provide different kinds of semantics - some want strict version-check,
some dont, some will have an fire-and-forget approach, some will not. I just
ment to say that for some of those types of semantics you want server-side Solr
to behave in a certain way. For that you probably need a configuration telling
the server how to behave. I have introduced that for updates with the
"semanticsMode" config on updatehandler.
I believe, when it comes to whether you want strict unique-key-constraint- and
version-checks or not, it is probably something you want to configure
server-side, so that you can control the possibilities of your clients. Not all
Solr-based systems will have complete control over all its clients, and then it
is nice on server-side to be able to say (using semanticsMode):
* consistency: I dont want you as a client to make updates to documents,
without even having read the existing document first (and merged your updates
into that), and I dont want you to be able to overwrite changes to that
document that happend to be made between the time you read it and the time you
provided your updated version. And I dont want you to incidentally overwrite an
existing document, if your intent was to create a new one.
* classic: All updates just go right into Solr, but you risk overwriting
exsisting stuff
* classic-concistency-hybrid: You can do both consistency and classic updates,
be casefull when doing classic updates
I believe this kind of control belongs in a server-side config, because it is a
way of "protecting" your data against badly written clients.
With respect to whether you want to do fire-and-forget or not, that should be
up to the client, but it kinda is by definition - basically just ignore
results. But fire-and-forget strategy on clients is really not worth much, if
you have to wait for the server to reply when you do updates (like you have to
do today). SOLR-3383 will provide a all-async client SolrJ API (Future-based
all the way) so that you can really just "fire", and if you intent is to
"forget" anyway, then you can move on immediately after your "fire" without
waiting for the server to reply.
That is not the reason we made SOLR-3383 though. It is because we want to be
able to get results back when using ConcurrentSolrServer, and that requires a
Future-based request API.
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-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
