PostgreSQL

CreateMultiple

7 samples, from the least code that works to complete workflows.

What a CreateMultiple does

Many records CreateMultipleAsync returns one id per entity, in list order (ids[i] is list[i]'s), each also set on its entity. All or nothing: if the call fails, nothing is stored, nothing is returned, and no entity gets an id. The same ArxEntity object twice in one list is ARX1001 (one entity holds one id). Rows with the same attributes in the same order are grouped, 20 or more as one array insert, under PostgreSQL's parameter limit, in one transaction
Without a catalog Every table in the list is read once, before the first row is written: one more round trip per call, not per row; still slower than with a catalog (Basic2)
Without ids new ArxCreateMultipleOptions { ReturnIds = false } reads no id back: a group of 5,000 rows or more of one shape goes in by binary COPY (smaller ones by the ordinary statement, faster below that size), values converted to each column's type; a group with a column COPY can't write (an enum, an array) takes the ordinary statement; all or nothing, and ArxRecordId.None for each entity (Basic3). From 0.1.0-preview.5

The samples

Basics

The least code that works.

1Create many records in one call and get their idsStandalone

Several records in one call, in seven scenarios. Three ways to declare the id column (in the service's schema, on each entity, in a schema for this one call), then two tables with no id column, then two things that only happen with many records: several tables in one list, and all or nothing when one record is refused.

2Create many records without a catalogStandalone

Many records in one call on a service created with only a connection string: accounts and a country in one list. ARX reads both tables from the database once, before it writes the first row, then returns one id per entity.

3Create many records without reading their idsStandalone

Many records created when the program doesn't need their ids: ReturnIds = false reads none back, and PostgreSQL loads a group of 5,000 rows or more of one shape with binary COPY. Still all or nothing.

Real cases

What an application does: a small CRM and product catalogue.

1Save an account's contacts in one callProgressive

A new customer's contacts, entered on one screen and saved in one call, in two scenarios: three contacts with different attributes, and a second save where one row fails, so none is stored.

2Import a 20,000-item product feed in one callProgressive

A supplier's product feed of 20,000 items, imported in one call, in three scenarios: the categories first, the feed itself (you don't split the list: ARX does, and keeps the call all or nothing), and next week's feed with a bad row, which refuses the whole feed.

Advanced cases

Dependency injection, transactions, batch scopes and setting the service up.

1Import 5,000 contacts in batches, in one transactionAdvanced

A 5,000-contact import in batches of 500, in one transaction that ARX manages (batch scopes), in three scenarios: automatic commit with RunBatchAsync; manual commit with BeginBatchAsync when you want to decide after a failed batch; and savepoints off when any failure must stop the whole import.

2An order and its lines: all steps or noneAdvanced

A process of several steps in one batch scope: create the order, create its lines, then check the payment. In two scenarios: the payment is declined, so neither the order nor its lines are kept (any step that fails, including your own code, undoes them all); and the payment is accepted, so both are committed together.