Enum BaseService<TEntity>.BulkVersionConflictPolicy

Namespace

FishMMO.Database.Npgsql.Services

Assembly

FishMMO-DB.dll

How a bulk versioned write should treat rows that lose the version race.

protected enum BaseService<TEntity>.BulkVersionConflictPolicy

Fields

Fail = 0

The batch is one indivisible statement and a skipped row invalidates the rows around it, so the whole write is rolled back.

Correct for slot-addressed layouts — inventory, bank, equipment, hotkeys — where a row's key is a position that its contents move between. Applying "the item is now in slot 5" without "slot 3 is now empty" leaves one item occupying two slots, which is item duplication, and applying the reverse loses it outright. The batch is a layout; half a layout is not a smaller layout, it is a wrong one.

SkipStaleRows = 1

Rows are independent facts. A row that loses to a newer write is correctly left alone and the rest of the batch stands.

Correct for template-addressed state — attributes, buffs, abilities, factions, quests, pets — where a row's key is its identity and never migrates. Two such rows have no bearing on one another, so there is nothing for a skipped row to corrupt.

Remarks

Every bulk upsert in this layer is gated EXCLUDED.version > table.version, so a row whose incoming version is not newer than what is already stored is simply not applied. Whether that is a failure depends entirely on what the batch means, and the two meanings need opposite handling.