Re: [hibernate-dev] 4.1.x and HHH-8092 aka no unique constraints after 4.1.10 upgrade
Thanks Guillaume.
One other issue was pointed out:
https://hibernate.atlassian.net/browse/HHH-8092?focusedCommentId=50658&am...
To my knowledge, there's not a reliable way to find existing constraints using
java.sql.DatabaseMetaData or queries (someone correct me if that's wrong). Therefore,
it will be either hard or impossible to know if a constraint already exists prior to a
schema update, leading to exceptions if it does.
Questions:
1.) Should we simply attempt to drop constraints before re-creating all of them on an
update?
2.) Was defaulting to unique constraints a bad idea? Switch to indexes or unique
columns?
3.) Was using randomly-generated constraint names a bad idea?
I thought we had many discussions and multiple inputs on the direction we went. But
I'm starting to think at least some of it was a mistake. I'd definitely
appreciate more input. Thanks!
Brett Meyer
Red Hat Software Engineer, Hibernate
----- Original Message -----
From: "Guillaume Smet" <guillaume.smet(a)gmail.com>
To: "Brett Meyer" <brmeyer(a)redhat.com>
Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org>
Sent: Thursday, April 4, 2013 5:34:06 PM
Subject: Re: [hibernate-dev] 4.1.x and HHH-8092 aka no unique constraints after 4.1.10
upgrade
On Thu, Apr 4, 2013 at 8:50 PM, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
If the patch for HHH-8092 is easy to backport, I can do it locally
if
you prefer? If it's not, it might effectively be a better idea to
cherrypick it yourself and post a snapshot.
Did it.
Looks far better:
"uc_curriculumvitaerating_1" UNIQUE CONSTRAINT, btree (code)
"uc_curriculumvitaerating_2" UNIQUE CONSTRAINT, btree (enumkey)
I'm going to publish the snapshots to our internal repository and move
all the applications we are working on currently to this
4.1.12-SNAPSHOT.
Will report if I see any problem in the next few days.
--
Guillaume