MigsLab MySQL
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 and value types go in multi-row INSERT statements of up to 1,000 rows or 1 MB of text (there is no parameter limit), all in one transaction. Their generated ids come back as one block per statement: LAST_INSERT_ID() is the first, the others follow by @@auto_increment_increment, and the row count is checked (with other inserts running too: see "Generated ids of many records") |
| 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: the same multi-row INSERT, the table resolved without needing an id; 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 idsStandaloneSeveral 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.
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.
Many records created when the program doesn't need their ids: ReturnIds = false reads none back, and needs no id column: on MySQL it is the same multi-row INSERT. Still all or nothing.
Real cases
What an application does: a small CRM and product catalogue.
1Save an account's contacts in one callProgressiveA 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.
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 transactionAdvancedA 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.
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.