[
https://issues.apache.org/jira/browse/SOLR-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-15150:
--------------------------------------
Attachment: SOLR-15150.patch
Status: Open (was: Open)
Attached patch implements this idea using a new
{{"require.inplace.atomic.updates"}} boolean param – suggestions for better
names would be appreciated.
The semantics of this param are such that it has no effect on regular updates
(ie: adding/replacing a document) but for any Atomic Update, a value of
{{"true"}} will cause the update to fail if the update can't be done In-Place.
I think these semantics are important, as it will allow solr admins to hardcode
{{"require.inplace.atomic.updates=true"}} in their {{/update}} handler defaults
if they wish...
{noformat}
$ curl -X POST -H 'Content-type:application/json' --data-binary '{
"add-field":{
"name":"inplace",
"type":"pint",
"multiValued":false,
"stored":false,
"indexed":false,
"docValues":true
}
}' http://localhost:8983/solr/techproducts/schema
{
"responseHeader":{
"status":0,
"QTime":427}}
$ curl 'http://localhost:8983/solr/techproducts/update?commit=true'
--data-binary '[{"id":"HOSS", "inplace":42}]'
{
"responseHeader":{
"status":0,
"QTime":143}}
$ curl
'http://localhost:8983/solr/techproducts/update?commit=true&require.inplace.atomic.updates=true'
--data-binary '[{"id":"HOSS", "inplace":{"set":99}}]'
{
"responseHeader":{
"status":0,
"QTime":62}}
$ curl
'http://localhost:8983/solr/techproducts/update?commit=true&require.inplace.atomic.updates=true'
--data-binary '[{"id":"HOSS", "name_s":{"set":"strings can not be updated in
place"}}]'
{
"responseHeader":{
"status":400,
"QTime":3},
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException"],
"msg":"Can not satisfy 'require.inplace.atomic.updates'; Unable to update
doc in-place: HOSS",
"code":400}}
{noformat}
> add request level option to fail an atomic update if it can't be done
> 'in-place'
> --------------------------------------------------------------------------------
>
> Key: SOLR-15150
> URL: https://issues.apache.org/jira/browse/SOLR-15150
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15150.patch
>
>
> When "In-Place" DocValue updates were added to Solr, the choice was made to
> re-use the existing "Atomic Update" syntax, and use the DocValue updating
> code if possible based on the index & schema, otherwise fall back to the
> existing Atomic Update logic (to re-index the entire document). In essence,
> "In-Place Atomic Updates" are treated as a (possible) optimization to
> "regular" Atomic Updates
> This works fine, but it leaves open the possibility of a "gotcha" situation
> where users may (reasonably) assume that an update can be done "In-Place" but
> some aspect of the schema prevents it, and the performance of the updates
> doesn't meet expectations (notably in the case of things like deeply nested
> documents, where the re-indexing cost is multiplicative based on the total
> size of the document tree)
> I think it would be a good idea to support an optional request param users
> can specify with the semantics that say "If this update is an Atomic Update,
> fail to execute it unless it can be done In-Place"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
