From d18c45390db28c01c0f0801606da183ebde02a8b Mon Sep 17 00:00:00 2001 From: Larry Leszczynski Date: Tue, 17 Oct 2017 09:56:50 -0600 Subject: [PATCH] Fix POD about using transactions with find_or_create The existing POD is misleading and causes people to think they can fix the find_or_create race condition just by putting it in side a transaction, but that does not actually help. --- lib/DBIx/Class/ResultSet.pm | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/lib/DBIx/Class/ResultSet.pm b/lib/DBIx/Class/ResultSet.pm index 030f2924b..70a8e2c2d 100644 --- a/lib/DBIx/Class/ResultSet.pm +++ b/lib/DBIx/Class/ResultSet.pm @@ -3001,8 +3001,12 @@ subsequently result in spurious row creation. B: Because find_or_create() reads from the database and then possibly inserts based on the result, this method is subject to a race condition. Another process could create a record in the table after -the find has completed and before the create has started. To avoid -this problem, use find_or_create() inside a transaction. +the find has completed and before the create has started. +Using find_or_create() inside a transaction I fix this problem - +if another process created the row after the transaction started, then when +the transaction with the newly-created row is committed, that insert +will either result in a duplicate row, or fail due to uniqueness +constraints. B: Take care when using C with a table having columns with default values that you intend to be automatically