About updates

The ingestRecords operation lets you incrementally update the data store running in the Oracle Endeca Server, including adding additional records.

Using the Data Ingest Web Service, you can perform the following types of incremental updates:

How updates are applied

The records to be added are considered totally additive. That is, if a record with the same primary key already exists in the data store, the key-value pair list of the added record will be merged with the existing record.

If a standard attribute with the same name already exists (but has a different assigned value), then the added attribute will be an additional value for the same attribute (multi-assign). For example, if the existing record has one standard attribute named color with a value of red and the request adds a color standard attribute with a value of blue, then the resulting record will have two color attributes.

Keep in mind, however, that you cannot add a second value to a single-assign attribute. (That is, a standard attribute whose PDR has the mdex-property_IsSingleAssign set to true.) In the color example, if color were a single-assign attribute and the record already had one color assignment, then an attempt to add a second color assignment would fail.

When adding standard attributes, the operation works as follows for the new standard attribute (i.e., the standard attribute to be added):
  • If the new standard attribute already exists in the data store but with a different type, an error is thrown and the new standard attribute is not added.
  • If the new standard attribute already exists in the data store and is of the same type, no error is thrown and nothing is done.
  • If the new standard attribute is a primary-key attribute and a managed attribute already exists with the same name, an error is thrown and the new standard attribute is not added.

Note that updating a record can cause it to change place in the default order. That is, if you have records ordered A, B, C, D, and you update record B, records A, C, and D remain ordered. However, record B may move as a result of the update, which means the resulting order might end up as B,A,C,D or A,C,B,D or another order.

Order of update operations

An ingestRecords request can contain all four types of updates. In this case, the order of processing is:
  1. deleteRecords requests are processed first.
  2. wildcardDeletes requests are processed second.
  3. deleteAssignments requests are processed third.
  4. addAssignments requests are processed last.

If a record is included in the deleteRecords element and is also included in one or more of the other elements, then the record is deleted and added again in the same transaction.

If a record attribute or attribute assignment is specified in the wildcardDeletes or deleteAssignments list and is specified again in the addAssignments list, then the attribute assignment is deleted and added again in the same transaction.

If identical records, standard attributes or assignments are specified in any of the elements, the redundant entries are ignored.

Affected records with update operations

The numRecordsAffected element in the ingestRecordsResponse lists how many records were affected (i.e., modified) by an ingestRecords operation.

However, it is possible that an affected record may not actually be changed by the operation. Any operation that results in the output record being the same as the input record will mark the record as affected but will leave it unchanged. These types of unaffected operations are adding an assignment that already exists, deleting an assignment that does not exist, performing a wildcard delete on a record property that has no assignments, and deleting an assignment and then adding the same assignment.