DDC-1716: Better unique constraints handling or even updateIfExists/findOneOrCreate #2160

New Issue

admin · 2026-01-22T13:43:00+01:00

admin commented

2026-01-22 13:43:00 +01:00

Originally created by @doctrinebot on GitHub (Mar 19, 2012).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user koc:

It is too hard handle rows duplication now. As adviced here http://stackoverflow.com/questions/3967226/checking-for-duplicate-keys-with-doctrine-2 we should catch \PDOException with code 23000. This is bad behavior.

So I propose:
a. Add DuplicateRowException wich will throwed by flush method (maybe wrapped PDOException) with method "getDuplicatedProperties" (based on sql error description parsing + mapping)
b. Add method findOneOrCreate (hello, Propel!) or updateIfExists to ObjectInterface, EntityManager
c. Combine a, b

Originally created by @doctrinebot on GitHub (Mar 19, 2012). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user koc: It is too hard handle rows duplication now. As adviced here http://stackoverflow.com/questions/3967226/checking-for-duplicate-keys-with-doctrine-2 we should catch \PDOException with code 23000. This is bad behavior. So I propose: a. Add DuplicateRowException wich will throwed by flush method (maybe wrapped PDOException) with method "getDuplicatedProperties" (based on sql error description parsing + mapping) b. Add method findOneOrCreate (hello, Propel!) or updateIfExists to ObjectInterface, EntityManager c. Combine a, b

admin added the New Feature label 2026-01-22 13:43:00 +01:00

admin commented

2026-01-22 13:43:01 +01:00

@doctrinebot commented on GitHub (Apr 19, 2012):

Comment created by dynom:

I don't think it should be limited to the flush method, however, as this can occur with "custom" queries also. It would be ideal if the errors being generated can be much more easily (read: standardized) caught or read.

I'm in favor of letting the database handle integrity checks, and not run a query to decide wether or not the update or insert queries will violate. Hence the desire to handle this more gracefully.

@doctrinebot commented on GitHub (Apr 19, 2012): Comment created by dynom: I don't think it should be limited to the flush method, however, as this can occur with "custom" queries also. It would be ideal if the errors being generated can be much more easily (read: standardized) caught or read. I'm in favor of letting the database handle integrity checks, and not run a query to decide wether or not the update or insert queries will violate. Hence the desire to handle this more gracefully.

admin commented

2026-01-22 13:43:01 +01:00

@doctrinebot commented on GitHub (Apr 19, 2012):

Comment created by lucasvanlierop:

The DBAL statement class (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Statement.php) has and execute method which might be a good place to catch and convert the generic PDOExceptions by wrapping the line

$stmt = $this->stmt->execute($params);

in a try/catch statement which then calls some kind of PDOException to Doctrine Exception method

@doctrinebot commented on GitHub (Apr 19, 2012): Comment created by lucasvanlierop: The DBAL statement class (https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Statement.php) has and execute method which might be a good place to catch and convert the generic PDOExceptions by wrapping the line $stmt = $this->stmt->execute($params); in a try/catch statement which then calls some kind of PDOException to Doctrine Exception method

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#2160