[hibernate-dev] unique constraint changes

[Brett Meyer]

https://github.com/hibernate/hibernate-orm/commit/40aaaa9ca769258cd4bfc67761d9cf0fca1ab56e

That reverted HHH-7797 in 4.1.  I just kicked off a build & snapshot release.  I'd feel much more comfortable about releasing 4.1.12.Final if some of you could grab and test 4.1.12-SNAPSHOT, once it's finished.

Brett Meyer
Red Hat Software Engineer, Hibernate

----- Original Message -----
From: "Brett Meyer" <brmeyer at redhat.com>
To: "Guillaume Smet" <guillaume.smet at gmail.com>
Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
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 at gmail.com>
To: "Brett Meyer" <brmeyer at redhat.com>
Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
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 at redhat.com> wrote:
> 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.

Sounds the best thing to do.

> 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.

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