Mutation for a specific table as part of a logical mutation on the entity. Functional behavior is driven by the specific subtypes:

• PreparableMutationOperation
• SelfExecutingUpdateOperation

example #1 - delete simple entity (Person) (1) MutationOperation(DELETE, person) example #2 - delete entity (Person) w/ secondary *non-optional* table (1) MutationOperation(DELETE, person) (2) MutationOperation(DELETE, person_supp) example #3 - insert simple entity (Person) (1) MutationOperation(INSERT, person) example #4 - insert entity (Person) w/ secondary *non-optional* table & IDENTITY id column (1) MutationOperation(INSERT, person) (2) MutationOperation(INSERT, person_supp) example #6 - update/merge entity (Person) w/ secondary *optional* table (1) MutationOperation(UPDATE, person) (2) MutationOperation(UPDATE, person_supp) - upsert / delete account for batching example #1 - insert entity (Person) w/ secondary *optional* table (1) MutationOperation(INSERT, person) - batched, all (2) MutationOperation(INSERT, person_supp) - batched, conditional[1] example #2 - delete entity (Person) w/ secondary table (1) MutationOperation(DELETE, person) - batched, all (2) MutationOperation(DELETE, person_supp) - batched, all example #3 - update/merge entity (Person) w/ secondary *optional* table (1) MutationOperation(UPDATE, person) - batched (2) MutationOperation(UPDATE, person_supp) - non-batched [1] For insertions with optional secondary tables, if the values are all null for that table we do not want to perform the "add-to-batch" handling for that specific "row"