Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The following page has been changed by HossMan: http://wiki.apache.org/solr/UpdateXmlMessages The comment on the change is: extracting content from CollectionBuilding New page: = XML Messages for Updating a Solr Index = Solr accepts POSTed XML messages that Add/Update, Commit, Delete, and Delete by query, using the url '''/update'''. Here is the XML syntax that SOLAR expects to see: [[TableOfContents]] == The Update Schema == (Not to be confused with [:SchemaXml:schema.xml].) === add/update === Example: {{{ <add> <doc> <field name="employeeId">05991</field> <field name="office">Bridgewater</field> </doc> </add> }}} ==== Optional attributes for "add" ==== * `allowDups = "true" | "false"` — default is "false" * `overwritePending = "true" | "false"` — default is negation of allowDups * `overwriteCommitted = "true"|"false"` — default is negation of allowDups The defaults for overwritePending and overwriteCommitted are linked to allowDups such that those defaults make more sense: * If allowDups is '''false''' (overwrite any duplicates), it implies that overwritePending and overwriteCommitted are '''true''' by default. * If allowDups is '''true''' (allow addition of duplicates), it implies that overwritePending and overwriteCommitted are '''false''' by default. ==== Optional attributes on "doc" ==== * `boost = <float>` — default is 1.0 (See Lucene docs for definition of boost.) ==== Optional attributes for "field" ==== * `boost = <float>` — default is 1.0 (See Lucene docs for definition of boost.) Example of "add" with optional attributes: {{{ <add allowDups="false" overwriteCommitted="true" overwritePending="true"> <doc boost="2.5"> <field name="employeeId">05991</field> <field name="office" boost="2.0">Bridgewater</field> </doc> </add> }}} === "commit" and "optimize" === Example: {{{ <commit/> <optimize/> }}} ==== Optional attributes for "commit" and "optimize" ==== * `waitFlush = "true" | "false"` — default is true — block until index changes are flushed to disk * `waitSearcher = "true" | "false"` — default is true — block until a new searcher is opened and registered as the main query searcher, making the changes visible. Example of "commit" and "optimize" with optional attributes: {{{ <commit waitFlush="false" waitSearcher="false"/> <optimize waitFlush="false" waitSearcher="false"/> }}} === "delete" by ID and by Query === Delete by id uses the uniqueKey field declared in the schema (in these examples, employeeId). Delete by id is much more efficient than delete by query. Example: {{{ <delete><id>05991</id></delete> <delete><query>office:Bridgewater</query></delete> }}} ==== Optional attributes for "delete" ==== * `fromPending = "true" | "false"` — default is "true" * `fromCommitted = "true" | "false"` — default is "true" Example of "delete" with optional attributes: {{{ <delete fromPending="true" fromCommitted="true"><id>05991</id></delete> <delete fromPending="true" fromCommitted="true"><query>office:Bridgewater</query></delete> }}} === Updating a Data Record via curl === You can use curl to send any of the above commands. For example: {{{ curl http://<hostname>:<port>/update --data-binary '/<add allowDups="false" overwriteCommitted="true" overwritePending="true"> <doc boost="2.5"> <field name="employeeId">05991</field> <field name="office" boost="2.0">Bridgewater</field> </doc> </add>' }}} {{{ curl http://<hostname>:<port>/update --data-binary '<commit waitFlush="false" waitSearcher="false"/>' }}} Until a commit has been issued, you will not see any of the data in searches either on the master or the slave. After a commit has been issued, you will see the results on the master, then after a snapshot has been pulled by the slave, you will see it there also.
