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

Ryan McKinley commented on SOLR-793:
------------------------------------

| One update request will have only one <add> 

That is the existing limitation, but i don't see any reason there could not be 
multiple <add> statements within one request.  similar to how we have multiple 
delete commands in one statement.

Our existing parser supports this already, only we would need to add a new root 
element.  This would allow a streaming client to post all commands sequentially 
to the server.

| The SolrInputDocument can have a 'commitWithin' attribute.

I don't like that because the 'commitWithin' attribute is about the command, 
not the data.  Attaching it to the 'add' command seems like the logical place 
for it.

> set a commit time bounds in the <add> command
> ---------------------------------------------
>
>                 Key: SOLR-793
>                 URL: https://issues.apache.org/jira/browse/SOLR-793
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>            Reporter: Ryan McKinley
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: SOLR-793-commitWithin.patch, 
> SOLR-793-commitWithin.patch, SOLR-793-deadlock.patch
>
>
> Currently there are two options for how to handle commiting documents:
> 1. the client explicitly starts the commit via <commit/>
> 2. set an auto commit value on the server -- clients can assume all documents 
> will be commited within that time.
> However, this does not help in the case where the clients know what documents 
> need updating quickly and others that could wait.  I suggest adding:
> {code:xml}
>  <add commitWithin="100">...
> {/code:xml} 
> to the update syntax so the client can schedule commits explicitly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to