Please see below...
On Sat, Dec 26, 2015 at 8:52 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
I'd prefer that IDENTITY never be the native generator any time
we add a
Native is a Hibernate-only concept and so we can really choose
we want for native generators. Also native is an outdated concept,
replaced by AUTO and SequenceStyleGenerator. IMO we should never be
choosing IDENTITY for identifier generation unless a user explicitly asks
Just to make sure I understand, are you saying we should not be choosing
IDENTITY by default for *new* dialects only?
So for the first piece, Oracle12cDialect should
override getNativeIdentifierGeneratorClass to
return SequenceStyleGenerator. The Dialect implementation
of getNativeIdentifierGeneratorClass really assumes databases which support
IDENTITY but not SEQUENCE.
Thanks for clarifying that. I was wondering about that.
Oracle12cDialect is the first case we have had where a database that
historically supported SEQUENCES has added support for IDENTITY and we just
did not account for that properly. In fact, the "proper" solution would be
to go into the base Oracle Dialect(s) and override
getNativeIdentifierGeneratorClass to just always
return SequenceStyleGenerator. But doing that in SequenceStyleGenerator
only is viable too.
Did you mean, "doing that in Oracle12cDialect only is viable too"?
As for how to get IDENTITY generation to work consistently with Oracle,
that I cannot say. I asked Oscar (the reporter of HHH-9983) for find out
the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
"Via JDBC" is the operative part. All of the Oracle documentation and
google hits at that time only discussed using IDENTITY via command told
(SQLPlus, etc). According to his findings we seem to have to correct.
I believe Oracle12cDialect identity support is working properly in master
IIUC you are saying that the problem is porting that from 5.1 (master) to
5.0? Due to an SPI change? What exactly is the SPI that changed?
make lots of changes to "IdentityColumnSupport" (adding that as a
first-class contract), but that is really just cosmetic grouping of stuff
already available on Dialect. So what change specifically stops you from
porting those changes to 5.0?
I've looked over the changes again and I think the main problem is that the
refactoring done for HHH-10084  will break custom dialects that override
the Dialect methods that are deprecated for 5.1. The deprecated Dialect
methods are no longer used; Hibernate obtains the identity support
information from Dialect#getIdentityColumnSupport only.
I've created a test to illustrate: .
Custom dialects will need to be modified to override
getIdentityColumnSupport() to work. Would this type of breaking change be
OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
breaking change in 5.0.
HHH-10084 () changed the deprecated Dialect methods to delegate to the
IdentityColumnSupport. It also extracted the overridden methods from
Dialect subclasses into dialect-specific IdentityColumnSupport classes.
If I backport HHH-9983 to 5.0, I think I would only backport part of
HHH-10084. I would change IdentityColumnSupportImpl methods to delegate to
the deprecated Dialect methods; I would not extract the overridden methods
into dialect-specific IdentityColumnSupport classes. That way, custom
dialects would not be broken.
What do others think about this breaking change in 5.1? If it's not
acceptable, then I propose making the same changes to master (backing out
of the changes where overridden methods are extracted into dialect-specific
IdentityColumnSupport). The extraction would be delayed until the
deprecated methods are removed (in 6.0?).
On Thu, Dec 24, 2015 at 4:58 AM Emmanuel Bernard
> I think my preference would be to override in Oracle*Dialect
> getNativeIdentifierGeneratorClass so that it always returns
> 1. it would be backward compatible with the logic we had for ever (with
> the exception of 5.0 but I understand that it is not really reliable)
> 2. I suppose sequences are still the preferred choices for Oracle DB DBAs.
> > On 24 Dec 2015, at 02:46, Gail Badner <gbadner(a)redhat.com> wrote:
> > Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
> > problems with the new identity support that Oracle12cDialect introduced
> > (HHH-9983). The fix for HHH-9983 involved SPI changes, so it was
> applied to
> > master for 5.1 (only).
> > A couple of weeks ago, Andrea found that identities seemed to work using
> > 5.0 when running BulkManipulationTest using Oracle JDBC 22.214.171.124.0. At
> > same time it failed for me in the same way as HHH-9983 using 126.96.36.199.0.
> > Then Andrea and I switched the JDBC versions (Andrea tried 188.8.131.52.0; I
> > tried 184.108.40.206.0) and we were both able to run BulkManipulationTest
> > successfully. This was very strange, especially since we were using the
> > same Oracle instance, each using a different user. I didn't see any
> > difference in how we were setting Hibernate properties. Several days
> > I tried Oracle JDBC 220.127.116.11.0 again, but BulkManipulationTest was
> > again in the same way as HHH-9983.
> > Does anyone know how to get Oracle12cDialect's identity support to work
> > 5.0 reliably? Is there some version of Oracle JDBC or DB configuration
> > is required?
> > If so, please let me know. The rest of this email assumes it is not
> > possible. If I'm missing some configuration detail, then just ignore the
> > rest of this message.
> > When the unit tests are run using Oracle12cDialect on 5.0, there are
> > failures:
> > * tests with entities explicitly mapped to use an identity fail; these
> > failures did not happen in 4.3 using Oracle10gDialect because these
> > where skipped (because Oracle10cDialect#supportsIdentityColumns returns
> > false)
> > * use @GeneratedValue with default strategy or use hbm mapping for ID
> > <generator class="native"/>; these failures did not happen in
> > the native generator for Oracle10gDialect uses a sequence; the native
> > generator for Oracle12cDialect uses an identity.
> > Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver
> > automatically resolve to Oracle12cDialect if the dialect is not
> > mapped. Previously it would have resolved ot Oracle10gDialect.
> > I would be OK with changing the native generator in 5.0 from sequence to
> > identity if identities were working properly. I think it will cause
> > confusion when applications break. To get things working with 5.0,
> > applications will need to explicitly set the dialect to
> > extend Oracle12cDialect to disable identity support, or change ID
> > to specify sequences.
> > Here are some alternatives to get things working.
> > Alternative A:
> > 1) for 5.0 through 5.x override
> > to return SequenceStyleGenerator.class; I suggest the change for 5.x
> > because I don't think it would be an acceptable to change the native
> > generator for Oracle12cDialect from using a sequence to using an
> > in 5.x;
> > 2) for 5.0 only, remove support for identities;
> > 3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is
> > at that time) to change the native generator to use an identity.
> > Alternative B:
> > 1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new
> > with native generator that uses a sequence (i.e.,
> > Oracle12cNativeSequenceGeneratorDialect or something else that is not so
> > ugly);
> > 2) for 5.0 through 5.x, change StandardDialectResolver to automatically
> > resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g
> > Alternative C:
> > 1) for 5.0 through 5.x, change native generator for Oracle12cDialect to
> > sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
> > 2) for 5.0 through 5.x, add a new dialect with native generator that
> > an identity (Oracle12cNativeIdentityGeneratorDialect or something else
> > is not so ugly).
> > 3) change StandardDialectResolver to automatically resolve to
> > Oracle12cDialect for Oracle 12g server.
> > I prefer alternative A. Alternatives B and C involve maintaining 2
> > for the same Oracle version; I would think that one of them would be
> > deprecated moving forward.
> > Thoughts?
> > Thanks,
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> hibernate-dev mailing list