When calling EntityManager persist() to create something that violates a unique key, hibernate always logs the error on persist call always logs before I have control to catch the exception and do my own logging. For example:
org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logExceptions Violation of UNIQUE KEY constraint ‘’. Cannot insert duplicate key in object '_’. The duplicate key value is (1, _____).
My problem isn’t the error itself, but rather that the error (unique constraint vilation) is not a problem in this case (on a high-activity table) and my logs are being flooded by these warnings that don’t matter at all. I’m seeing this question asked online as far back as 2005 so I’m not sure there’s really a fix for this, but can anything be done?
Also if there is no choice but to have whether this will be logged or not fall to logging.properties settings, is there a way that I can make those settings more or less just hide this sort of error? I saw this elsewhere regarding the JDBCExceptionReporter, is this sort of thing supposed to work in logging.properties?
org.hibernate.util.JDBCExceptionReporter=false
org.hibernate.util.JDBCExceptionReporter=INFO, rolling
I don’t think you can selectively disable just this unique constraint violation exception logging, but what you can do, is use @SQLInsert to make use of a ON CONFLICT clause. This way, you transform inserts into upserts and can decide to skip on conflict or do an update.
Thanks Christian, I wasn’t aware of this option. We’re trying to stick with JPA but I’ll see if use of the hibernate annotations library is acceptable.
I think you can also use the xml mapping for this purpose if you like that more, but I would recommend you to use the annotation approach as it is easier. I would also recommend to rethink your approach and use the Hibernate features/annotations if possible/needed to get the best out of it. Working around it to be “standards compliant” rarely is a good idea and usually leads to bad performance.