Schrijven & offline

Schrijven met hetzelfde model

const { id } = await db.task.create({
  data: { title: "Ship it", column: { connect: columnId } },
});

await db.task.update({ where: { id }, data: { done: true } });
await db.task.upsert({ where: { id }, create: { title: "A" }, update: { title: "B" } });
await db.task.delete({ where: { id } });

await db.column.update({
  where: { id: columnId },
  data: { tasks: { connect: [a, b], disconnect: [c] } },
});

// Meerdere schrijfacties, één logregel, alles of niets
await db.$transaction([
  db.task.update({ where: { id: a }, data: { position: 2 } }),
  db.task.update({ where: { id: b }, data: { position: 1 } }),
]);

create faalt als de id bestaat; update faalt als de rij ontbreekt; upsert kiest binnen de transactie van de engine, dus het kan niet racen.

Schrijfacties worden optimistisch toegepast, wachten offline in een IndexedDB-outbox en resolven naar { id, status: "applied" | "queued" }. Een schrijfactie die de engine tijdens een achtergrondflush definitief weigert, komt bij onWriteRejected terecht.

Retries worden gededupliceerd op client-transactie-id. Duurzame receipts overleven snapshots, logopschoning en herstel uit R2, dus een eerder toegepast verzoek wordt bevestigd zonder het opnieuw toe te passen. Dezelfde id met andere operaties hergebruiken wordt geweigerd.

Gerelateerde rijen

Gerelateerde rijen kunnen samen met de rij die ze nodig heeft worden aangemaakt:

await db.board.create({
  data: {
    name: "Launch",
    columns: { create: [{ name: "Todo", position: 1, tasks: { create: { title: "Ship" } } }] },
  },
});

await db.column.create({ data: { name: "Solo", board: { create: { name: "New board" } } } });

Het is één transactie, zo geordend dat elke rij bestaat voordat iets ernaar wijst, en één fout draait de hele boom terug. De types volgen één niveau; diepere nesting controleert de engine.

Veel rijen schrijven

const { count } = await db.task.updateMany({ where: { done: true }, data: { archived: true } });
await db.task.deleteMany({ where: { columnId: null } });

De engine bepaalt binnen de transactie welke rijen matchen en logt de rijen in plaats van het filter. Een replay moet veranderen wat het origineel veranderde, en een filter later opnieuw draaien kan dat niet beloven. Een bulkwrite raakt alleen rijen die de caller mag lezen, en draait de rijregels voor update en delete nog steeds op elke rij.

Maximaal 1.000 matchende rijen committen als één transactie. Daarboven schrijft de client batches van 1.000 in id-volgorde, elk zijn eigen transactie, tot het filter uitgeput is; count is het totaal. Als een batch faalt, zegt BulkWriteError.written hoeveel rijen de eerdere batches wijzigden, en dezelfde aanroep opnieuw doen gaat verder met wat nog matcht.

Anders dan schrijfacties op één rij worden bulkwrites niet optimistisch toegepast en niet offline in de wachtrij gezet: welke rijen matchen is het antwoord van de engine, niet van de cache.