[jira] [Updated] (SOLR-15150) add request level option to fail an atomic update if it can't be done 'in-place'

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org