Adding records after the initial load

This topic describes the addOrUpdateRecords sub-operation.

The addOrUpdateRecords sub-operation allows you to add more records to the data domain at any time after the initial loading of records is complete. addOrUpdateRecords works as follows:
  • If the specified primary key (record specifier) does not exist in the current data set, the record is added with the primary key and the specified assignments. This mode is like the addRecords sub-operation.
  • If the specified primary key already exists in the current data set, the record is updated with the new assignments. This mode is like the updateRecords sub-operation.
Adding more records after the data domain is created and its Dgraph process is up and running with the initially-loaded record set is very similar to the initial-load scenario, which means:
  • You use the ingestChanges operation with either the addRecords sub-operation (described earlier in this chapter) or the addOrUpdateRecords sub-operation (described in this topic).
  • You identify new records by adding assignments on their primary-key attribute.
  • As with an initial load operation, standard attributes are created as needed when non-existent attributes are specified for a new record. The PDR for the standard attribute will use the system default settings.
  • If a standard attribute is configured as multi-assign, a record can have multiple assignments of that attribute.
  • You can add multiple records with the same request.
  • You can update other, existing records with the same ingestChanges request, by using the updateRecords sub-operation.
  • Records that are being added are not available for other operations in the same request.
  • You can delete other records in the same request, by using the deleteRecords sub-operation.

addOrUpdateRecords request

The addOrUpdateRecords basic syntax is: 
<ingestChanges>
   <addOrUpdateRecords>
      <recordSpecifier>
         <attribute name="?" type="?">?</attribute>
      </recordSpecifier>
      <addAssignments>
         <attribute name="?" type="?">?</attribute>
      </ns:addAssignments>
   </addOrUpdateRecords>
</ingestChanges>
where:
  • The recordSpecifier element contains the name and value of the primary-key attribute. Note that the primary-key attribute must already exist.
  • The addAssignments element contains the names and values of the attributes to be assigned to the record. If a specified attribute does not exist, it is created with default system values.
For example, this request adds one record with two assignments to the data domain: 
<soapenv:Envelope 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:ns="http://www.endeca.com/MDEX/ingest/3/0" 
  xmlns:ns1="http://www.endeca.com/MDEX/XQuery/2009/09">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:ingestChanges>
          <ns:addOrUpdateRecords>
            <ns:recordSpecifier>
               <ns1:attribute name="partID">8345</ns1:attribute>
            </ns:recordSpecifier>
            <ns:addAssignments>
               <ns1:attribute name="color">blue</ns1:attribute>
               <ns1:attribute name="price">29.99</ns1:attribute>
            </ns:addAssignments>
         </ns:addOrUpdateRecords>
      </ns:ingestChanges>
   </soapenv:Body>
</soapenv:Envelope>

Note that none of the key-value assignments specify an attribute type (such as the type for the price attribute, which is mdex:double). This is because all the attributes already exist in the data domain and therefore already have a type that was assigned when they were initially created (unless specified, the default string type was used). The type of the assignment attribute value must match the type of the attribute.

Note: If you submit the ingestChanges request after a Transaction Web Service request that starts an outer transaction, the request must specify the outer transaction ID. If no outer transactions have been started, the ID attribute must be omitted in the request.