Thanks for demoing this today, Bill. From the demo earlier, I think it looks really good! I'm curious, though: is there any benefit to retaining the old all-in-one-transaction behavior? I'd propose simply using the new per-record transactions always, rather than asking catalogers to choose between the two.
If there are benefits to retaining the old behavior for smaller batches, maybe the API could be smart enough to make the determination of how to handle transactions (if number_of_records_to_change < some_configurable_number_with_a_sensible_default). It just seems to me like an implementation detail that catalogers shouldn't have to learn about or decide on.
Thanks for demoing this today, Bill. From the demo earlier, I think it looks really good! I'm curious, though: is there any benefit to retaining the old all-in- one-transaction behavior? I'd propose simply using the new per-record transactions always, rather than asking catalogers to choose between the two.
If there are benefits to retaining the old behavior for smaller batches, maybe the API could be smart enough to make the determination of how to handle transactions (if number_ of_records_ to_change < some_configurab le_number_ with_a_ sensible_ default) . It just seems to me like an implementation detail that catalogers shouldn't have to learn about or decide on.