On Mon, Sep 19, 2022 at 8:42 PM Daniel Rodgers-Pryor < [email protected]> wrote:
> I recently came accross these additional transactions when profiling our > app. Would you be open to a PR which removes the transactions when they're > not needed (when the group of inserts is a single statement)? > I took a more detailed look at this and am now in favor of the change. Looking at the MSSQL support, it is already broken in regards to transactions. It runs the equivalent of BEGIN, COMMIT, INSERT. I don't think it can result in broken behavior though, since it only runs a single INSERT (uses :values or :union multi insert strategy). So on MSSQL, the transaction code can be removed completely. On PostgreSQL, the transaction code can be removed for the same reasons, though at least it isn't currently broken. In the generic code, I think it's only worth optimizing the default case, and not the case where return: :primary_key is used. I would use a simple if/else for that, and avoid a lambda-approach like DUMMY_TRANSACTION earlier in the thread. That will require additional/modified core specs as well as additional integration tests. The documentation should also be updated appropriately. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/CADGZSSd%3D-BgAXxKaTu%3D9D-1D2v%2Bw_sXCeWFd-smh_BVgDggJdw%40mail.gmail.com.
