Oracle12cDialect identity support
by Gail Badner
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 12.1.0.1.0. At the
same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
tried 12.1.0.2.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 later,
I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was failing
again in the same way as HHH-9983.
Does anyone know how to get Oracle12cDialect's identity support to work for
5.0 reliably? Is there some version of Oracle JDBC or DB configuration that
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 many
failures:
* tests with entities explicitly mapped to use an identity fail; these
failures did not happen in 4.3 using Oracle10gDialect because these tests
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 4.3 because
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 will
automatically resolve to Oracle12cDialect if the dialect is not explicitly
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 Oracle10gDialect,
extend Oracle12cDialect to disable identity support, or change ID mappings
to specify sequences.
Here are some alternatives to get things working.
Alternative A:
1) for 5.0 through 5.x override Dialect#getNativeIdentifierGeneratorClass
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 identity
in 5.x;
2) for 5.0 only, remove support for identities;
3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is current
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 dialect
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 server.
Alternative C:
1) for 5.0 through 5.x, change native generator for Oracle12cDialect to use
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 uses
an identity (Oracle12cNativeIdentityGeneratorDialect or something else that
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 dialects
for the same Oracle version; I would think that one of them would be
deprecated moving forward.
Thoughts?
Thanks,
Gail
10 years, 2 months
Activate URL links on blog
by Vlad Mihalcea
Hi,
Since we are now moderating the forum and disallow new users from posting,
we can activate links on the forum to increase user experience.
What do you think?
Vlad
10 years, 2 months
Hibernate ORM and Java 8 usage
by Steve Ebersole
The use of Java 8 features in Hibernate ORM is starting to expand. Luckily
it is still constrained to just tests.
However these usages make development in an IDE more and more difficult.
Previously this was isolated to hibernate-infinispan. Now[1] this has
crept into hibernate-entitymanager. We need to have a plan here. Either
we stop using Java 8 anywhere, or we move to Java 8 and rely on
AnimalSniffer to make sure we are still compatible.
Votes? Other options?
[1]
https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed...
10 years, 2 months
Issue a warning if field and getter annotation styles are mixed?
by Gunnar Morling
Hi,
Would it be feasible to raise a warning or error in cases where
mapping annotations are given on an element not matching the default
access type for that entity and @Access has not been given explicitly
either?
The most common case of this issue which I saw several times happen is
where @Id is given at the field level but some other mapping
annotations are given on property getters. The latter are silently
ignored in that case, resulting in mapping errors tough to understand
for those not super-deep into the details of access type retrieval. A
warning might help them.
Any thoughts?
--Gunnar
10 years, 2 months
Oracle running on CI
by Sanne Grinovero
Hi Steve,
when explicitly setting the Dialect to an empty string I have several
failures; when leaving it as-is I believe this run was valid though,
at least that's the feeling I'm getting from the kind of failures:
http://ci.hibernate.org/view/ORM/job/hibernate_orm_master_oracle/ws/hiber...
Some tests are failing, but a significant amount is passing just fine
and the logs seem to indicate that it's using the Oracle testing
instance.
Also, setting the dialect seems consistent with other matrix configurations?
Thanks,
Sanne
10 years, 2 months
Not letting Jenkins auto-close PRs upon build failures
by Gunnar Morling
Hi,
Not sure whether that's a new behaviour, but it's super annoying that
the pull request builder automatically closes pull requests if there
is a build failure. Can we change this so the PR stays open, please?
The current behaviour is highly frustrating, you need to re-open the
PR again after fixes, and in the worst case a PR falls through the
cracks because it's moved out to the "Closed" tab right away. It's
especially bad for contributor PRs where the failure is caused by
ourselves, e.g. build environment issues.
Thanks,
--Gunnar
10 years, 2 months
Is the the optional=false @OneToOne lazy retrieval still relevant
by Vlad Mihalcea
Hi,
I remember that for a bidirectional @OneToOne relationship, the optional =
false attribute could instruct Hibernate to always generate a Proxy
(because this association cannot be null),
so, if the fetch is LAZY, it would not generate a secondary query upon
fetching the parent-side entity.
I tested it with the latest Hibernate, and when fetching the parent entity
it always generates the secondary select for the child entity too.
Is this optimization not relevant anymore or is it an issue?
Vlad
10 years, 2 months
