On Wed, Apr 3, 2013 at 4:52 PM, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: In case you're interested, the regression we have with 4.2.x is the following: https://jira.springsource.org/browse/SPR-10395 . It will probably be fixed in the next version of Spring 3.2.x if fixing it doesn't break the 4.1.x support. You can see in the comments that they consider that Spring 3.2.x is mainly targeted for 4.1.x so it might be worth it to have a final version of 4.1.x without any "obvious" bugs as Spring 4.0 won't be released soon. -- Guillaume

Hi Brett, On Thu, Apr 4, 2013 at 5:48 PM, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: I agree with you that this fix should have been put only in 4.2.x and, even if I don't find any problem with our applications with HHH-8092 applied, I must admit that I would suggest to revert the patch entirely as it's rather invasive and I'm not sure we have found all the problems so far. That said, I'm not the original reporter so I'm kinda biased... No problem to test that everything is OK for us with HHH-8092 applied and I'll let you decide what you prefer after that. 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. Nice, thanks. We had to go back to 4.1.6 at the moment as it's the only version which works with all our projects (except for the ones using SQL Server but we use another version specifically for these ones). Waiting for your feedback before working on it. Thanks. -- Guillaume

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&gt; To: "Brett Meyer" <brmeyer(a)redhat.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; 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&gt; wrote: 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

Here's what I'd like to do. In 4.1.x, all of the unique constraint/index/column changes from HHH-7797 [1] and the random constraint names in HHH-1904 [2] will be reverted. When we originally started working on them, they weren't intended to be this complex. We'll cut a new 4.1.x release. But as always, the rabbit hole is deep. The changes will be kept in 4.2 & 4.3. I'll wait a while before reverting and pushing in 4.1. If there are any objections, please say so ASAP. Regarding the concern brought up in HHH-8092 [3] (constraints re-generated in schema update, even if they exist): Defaulting to unique constraints, as opposed to indexes or unique columns, was the best route and most widely supported. As discussed, it's difficult and un-reliable to attempt to find existing constraints prior to updating. And remember that schema generation was never meant to be used for production environments -- supporting every single use case and situation is impossible. "and I'm curious of what you obtain in validate mode" Schema validation currently checks tables, columns, and sequences only. All that being said, I'm definitely up for improvement suggestions in 4.2/4.3. Feel free to create tickets and we'll discuss them. Guillaume, thanks much for the input. [1] https://hibernate.atlassian.net/browse/HHH-7797 [2] https://hibernate.atlassian.net/browse/HHH-1904 [3] https://hibernate.atlassian.net/browse/HHH-8092?focusedCommentId=50658&am... Brett Meyer Red Hat Software Engineer, Hibernate ----- Original Message ----- From: "Guillaume Smet" <guillaume.smet(a)gmail.com&gt; To: "Brett Meyer" <brmeyer(a)redhat.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Friday, April 5, 2013 4:40:45 AM Subject: Re: [hibernate-dev] 4.1.x and HHH-8092 aka no unique constraints after 4.1.10 upgrade Hi Brett, On Fri, Apr 5, 2013 at 2:38 AM, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: Oh, yeah. I started the application only once last night to check for the constraints creation. And another problem came to my mind this morning. What if I update an existing database to 4.1.12-SNAPSHOT: I'm going to have twice the same constraints (which is going to lead to twice the same index in PostgreSQL - bad idea for write performances and query planning time). Here is what I obtain on a database created before 4.1.10 after an upgrade to 4.1.12-SNAPSHOT: Indexes: "uk_user__followedticket_1" UNIQUE CONSTRAINT, btree (followingusers_id, followedtickets_id) "user__followedticket_followingusers_id_followedtickets_id_key" UNIQUE CONSTRAINT, btree (followingusers_id, followedtickets_id) Apart from more questions, I think this behaviour and your line of questioning give us at least a clear answer: we should revert these patches entirely for the time being and see if we can find an acceptable solution based on your patch, which looks good from a design point of view but definitely needs more thoughts on the upgrade path in update mode (and I'm curious of what you obtain in validate mode with a preexisting database). And if this patch ever gets commited, it should be in a x.x.0 release with a prominent release note about the upgrade, not in a maintenance release. That said, here are my 2 cents about your questions: Right. For a few databases (the ones which implement unique constraints with unique indexes), getIndexInfo can give you part of the information but it's not reliable and incomplete. No. I often create additional objects in my database aka the ones you cannot create with Hibernate (partial or implementation specific indexes, exclusion constraints...). You cannot drop what's in the database in update mode. I don't think I can help with this one. I'm a bit too much a PostgreSQL specialist where unique constraints are indeed implemented as unique indexes. I don't know the implementation details of the other databases and if it's a good idea for them. Unique indexes and unique columns sound appealing as you'll be able to get the information from JDBC. The update path point pointed above still stands... Personnaly not my bag of tea. Did you do it to mitigate the problem with identifier name length limits? The update path point pointed above is also to consider for this type of changes... Happy to discuss these issues further with you if needed. -- Guillaume

We cannot simply remove unique constraint generation on an update all-together -- although you have a good point about the exceptions, many users still rely on that functionality. Instead, let's make it configurable. A property would select from the following: 1.) Update ignores all unique constraints 2.) Update drops *all* unique constraints and re-creates them 3.) Update attempts to (re-)create the unique constraints and ignores any errors Any other options? I'd argue that #3 would be the default. #2 is problematic for DBs that have non-mapped constraints. Brett Meyer Red Hat Software Engineer, Hibernate ----- Original Message ----- From: "Guillaume Smet" <guillaume.smet(a)gmail.com&gt; To: "Brett Meyer" <brmeyer(a)redhat.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Saturday, April 6, 2013 12:40:27 PM Subject: Re: unique constraint changes Hi Brett, Thanks for following up on this. My comments below. On Fri, Apr 5, 2013 at 6:44 PM, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: Sounds the best thing to do. Here is where I don't follow you because "update" mode is very widely used, especially in development environments but probably also in production. My 2 cents: - You can't have a behaviour where you have a ton of SQL error messages at each startup. The way it worked before was a better compromise IMHO: the unique constraints were created only at table creation. It wasn't perfect but was the best compromise we can find IMHO, when you are in update mode. - You can't publish a maintenance release with a major change in the naming scheme. Releasing it as a 4.2.0 sounds sane. BUT you have to clearly mention it in the release notes with all the problems it can cause to the users. And perhaps provide guidance on how to update without too much pain. As a long time Hibernate user trying to keep up with the releases to provide feedback from the field to the Hibernate (and Search) team as soon as possible (and sometimes fixing bugs), I was quite surprised by this change and I would have liked to be warned in the release announcement. HTH -- Guillaume

The unique constraint changes are reverted in 4.1.12-SNAPSHOT. I'm following this discussion up with https://hibernate.atlassian.net/browse/HHH-8162. Any further comments, please leave them there. Thanks! Brett Meyer Red Hat Software Engineer, Hibernate ----- Original Message ----- From: "Brett Meyer" <brmeyer(a)redhat.com&gt; To: "Guillaume Smet" <guillaume.smet(a)gmail.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Monday, April 8, 2013 1:37:26 PM Subject: Re: unique constraint changes We cannot simply remove unique constraint generation on an update all-together -- although you have a good point about the exceptions, many users still rely on that functionality. Instead, let's make it configurable. A property would select from the following: 1.) Update ignores all unique constraints 2.) Update drops *all* unique constraints and re-creates them 3.) Update attempts to (re-)create the unique constraints and ignores any errors Any other options? I'd argue that #3 would be the default. #2 is problematic for DBs that have non-mapped constraints. Brett Meyer Red Hat Software Engineer, Hibernate ----- Original Message ----- From: "Guillaume Smet" <guillaume.smet(a)gmail.com&gt; To: "Brett Meyer" <brmeyer(a)redhat.com&gt; Cc: "Hibernate" <hibernate-dev(a)lists.jboss.org&gt; Sent: Saturday, April 6, 2013 12:40:27 PM Subject: Re: unique constraint changes Hi Brett, Thanks for following up on this. My comments below. On Fri, Apr 5, 2013 at 6:44 PM, Brett Meyer <brmeyer(a)redhat.com&gt; wrote: Sounds the best thing to do. Here is where I don't follow you because "update" mode is very widely used, especially in development environments but probably also in production. My 2 cents: - You can't have a behaviour where you have a ton of SQL error messages at each startup. The way it worked before was a better compromise IMHO: the unique constraints were created only at table creation. It wasn't perfect but was the best compromise we can find IMHO, when you are in update mode. - You can't publish a maintenance release with a major change in the naming scheme. Releasing it as a 4.2.0 sounds sane. BUT you have to clearly mention it in the release notes with all the problems it can cause to the users. And perhaps provide guidance on how to update without too much pain. As a long time Hibernate user trying to keep up with the releases to provide feedback from the field to the Hibernate (and Search) team as soon as possible (and sometimes fixing bugs), I was quite surprised by this change and I would have liked to be warned in the release announcement. HTH -- Guillaume