PostgreSQL
UpdateMultiple
6 samples, from the least code that works to complete workflows.
What an UpdateMultiple does
| Many rows | Rows with the same attributes go in one statement (UPDATE … FROM unnest(…), one array per column), wherever they are in the list |
| Without a catalog | The table is read once for the whole list, then every row is changed, all or nothing (Basic2) |
| By a filter | One entity with the values to set and an ArxFilterExpression: one UPDATE … SET … WHERE … for every row the filter matches, returning the count (Basic3). The entity carries no id (ARX1001); an empty filter needs AllRows; a version column goes up by one on each changed row. From 0.1.0-preview.5 |
The samples
Basics
The least code that works.
1Update many records in one callStandaloneMany records in one call, in three scenarios: a different value for each row, rows that change different attributes, and all or nothing when one record doesn't exist.
Many records in one call on a service created with only a connection string: the account table is read from the database once for the whole list, then every row is changed, all or nothing.
Every row a condition matches, changed in one call: the entity carries only the values to set, and a filter says which rows. The call returns how many rows it changed.
Real cases
What an application does: a small CRM and product catalogue.
1Put accounts on hold (selection set, by key)ProgressiveCredit control puts accounts on hold, in three scenarios: one account by its account number (the declared key); a value the status picklist doesn't allow is refused before the database; every account of a segment at once.
A supplier's price feed reprices the catalogue, in two scenarios: 20,000 products by SKU in one call (one set-based statement), and a feed with a SKU the catalogue doesn't have, which changes nothing.
Advanced cases
Dependency injection, transactions, batch scopes and setting the service up.
1Stock counts in batches: one transaction, a failed batch skippedAdvancedA stock count file updates products in batches, in two scenarios: every batch in one transaction with automatic commit; and a batch that fails, skipped while the others are kept (savepoints, manual commit).