Batch Operations

AddMany and RemoveMany commit a whole batch in one transaction โ€” two round trips regardless of batch size, against one per keyword for a loop over Add.

result, err := ac.AddMany([]string{"he", "her", "him", "his"}, &acor.BatchOptions{
    Mode: acor.BatchModeTransactional,
})
if err != nil {
    panic(err)
}

fmt.Printf("Added: %d, Failed: %d, Skipped: %d\n",
    len(result.Added), len(result.Failed), len(result.Skipped))

nil options mean best-effort, which is also what BatchOptions with no Mode selects.

Modes

ModeOn a per-keyword failure
BatchModeBestEffort (default)Commits the rest; failures land in result.Failed, and the call still returns success
BatchModeTransactionalRolls the whole batch back and returns an error

Inspect what best-effort dropped:

for _, ke := range result.Failed {
    fmt.Printf("%q failed: %v\n", ke.Keyword, ke.Error)
}

result.Skipped holds duplicate adds and absent removes โ€” not errors. Field-by-field shapes for BatchResult and KeywordError are in the API reference.

For sentinel and structured error handling, see the API error-handling guidance.

Scanning many texts

FindMany loads the automaton once and scans every text against that one snapshot, so it costs the same round trip as a single Find. The result is keyed by the input text.

texts := []string{"he is him", "this is hers", "hello world"}
results, err := ac.FindMany(texts)
if err != nil {
    panic(err)
}

for text, matches := range results {
    fmt.Printf("Text %q: %v\n", text, matches)
}

Sizing

100โ€“1,000 keywords per batch is the useful range: below it the transaction overhead dominates, above it the single Lua commit grows large enough to block Redis noticeably. Measured costs are on the benchmarks page.