@OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element
by Gail Badner
The fix for HHH-12436 involves correcting the foreign key direction for
"real" one-to-one associations. I've been looking into the ramifications of
this change because I'm concerned that applications can rely on the old
(incorrect) foreign key direction.
In the process I've found that Hibernate treats:
@OneToOne
@PrimaryKeyJoinColumn
private Employee employee;
differently from:
@OneToOne
@MapsId
private Employee employee;
I believe they should be treated consistently. You can see my reasoning
below. [1]
Before going into details about how they are treated differently, I'd like
to get confirmation, in case I am missing some subtlety.
Could someone please confirm this?
Regards,
Gail
---------------------------------------------------------------------------------------------
[1]
In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId without
the value element as follows:
@MapsId
@JoinColumn(name="FK")
@OneToOne Person patient;
This example has the following footnote:
"[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would
result in the same mapping in this example. Use of MapsId
is preferred for the mapping of derived identities."
The description has a footnote that says that using PrimaryKeyJoinColumn
instead of MapsId would result in the same mapping.
In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses
@PrimaryKeyJoinColumns as follows:
@OneToOne
@PrimaryKeyJoinColumns({
@PrimaryKeyJoinColumn(name="ID",
referencedColumnName="EMP_ID"),
@PrimaryKeyJoinColumn(name="NAME",
referencedColumnName="EMP_NAME")})
EmployeeInfo info;
This example has the following footnote:
"[123]Note that the derived identity mechanisms decribed in section 2.4.1.1
is now preferred to the use of PrimaryKeyJoinColumn for
this case."
6 years, 3 months
Re-enabling the BlueOcean interface in Jenkins
by Yoann Rodiere
Hi,
We're about to make use of Jenkins pipelines in Hibernate Search, and for
that purpose, the BlueOcean is much easier to read. So I'd like to
re-enable it.
This should not affect other projects much, as the default interface when
you go to ci.hibernate.org will still be the "old" one. However, this will
unfortunately change the URL in emails sent by Jenkins so that the URL
points to the BlueOcean interface; and unfortunately, there doesn't seem to
be a way around that. You do have a button on the top right of the
BlueOcean interface to go back to the "old" interface, though.
For anyone wondering, this
<https://plugins.jenkins.io/blueocean-display-url> is the plugin
responsible for this behavior, and we can't uninstall it as long as
BlueOcean is installed.
Given the inconvenience is minor, and pipeline logs are pretty much
unreadable without the interface (seriously, good luck spotting the problem
in this
<http://ci.hibernate.org/view/Search/job/hibernate-search-6-poc/job/HSEARC...>),
is it alright for everyone if I re-enable the BlueOcean interface?
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years, 3 months
NoORM IRC meeting minutes
by Guillaume Smet
Hi,
Here are the minutes of this week's meeting.
Bot is on PTO so I copy/paste everything below:
15:01 < gsmet> #topic Progress Fabio
15:01 < fax4ever> Hi all
15:01 < fax4ever> I've come back yesterday from holidays,
15:01 < fax4ever> so I was most of the time on holiday in the last two
weeks.
15:01 < fax4ever> I resumed to work on the issue that I left pending.
15:01 < fax4ever> The one to make no longer mandatory the persistence
provider.
15:01 < fax4ever> We had a good meeting on this topic just before my
vacations with Davide and Sanne,
15:02 < fax4ever> where Sanne pointed out a possible *nice* solution.
15:02 < fax4ever> The solution would require to change some code in
Hibernate ORM too, in order to solve the issue.
15:02 < fax4ever> The good news is that the ORM provider class
`HibernatePersistenceProvider`:
15:02 < fax4ever> is currently capable to handle perfectly the OGM's cases
too.
15:02 < fax4ever> I made some test and I discovered that if the property
`hibernate.ogm.enabled` is set to `true`,
15:02 < fax4ever> this class might active OGM's cases without any need of
the OGM provider class:
15:02 < fax4ever> `HibernateOgmPersistence`.
15:02 < fax4ever> Then I think that most part of the job has been already
done.
15:03 < fax4ever> That's all about my progress. Thank you!
15:03 < gsmet> thanks
15:03 < gsmet> #topic Next 2 weeks Fabio
15:03 < fax4ever> Firstly, I'm implementing the `persistence provider`
issue.
15:03 < fax4ever> For the reasons that I've explained before,
15:03 < fax4ever> I think that we'll need a very limited change of code on
both OGM and ORM projects.
15:03 < fax4ever> Secondly, I believe that the priority will be the
OGM/Infinispan presentation on September,
15:03 < fax4ever> arranged by Paolo Menon.
15:04 < fax4ever> Therefore I'm going to spend some time on Hibernate demo
project.
15:04 < fax4ever> Thirdly, I might spent some time on minor issues,
15:04 < fax4ever> such as adding more tests on Java time mapping and so on.
15:04 < fax4ever> Fourthly, I would like to spend other time to review some
PRs.
15:04 < fax4ever> Fifthly, I don't know if a new release is scheduled, in
case it is, I could help to handle it.
15:04 < fax4ever> Finally, after next two weeks I will be on PTOs again,
just for one week.
15:04 < fax4ever> That's all about my next two weeks. Thank you!
15:05 < gsmet> thanks Fabio
15:05 < gsmet> #topic Progress Guillaume
15:05 < gsmet> so a good part of my last 2 weeks was the Search F2F
15:05 < gsmet> we made some good progress there but I'll let Yoann give
more details if he sees fit
15:06 < gsmet> I also released a new HV for inclusion in WF 14 due to a few
issues
15:06 < gsmet> and continued to coordinates the ORM 5.3 work
15:06 < gsmet> we are discussing some patches related to the security
manager right now
15:06 < gsmet> discussing means me sending emails and not getting answers :)
15:07 < gsmet> other than that I made some progress on the projection DSL
for Search 6
15:07 < gsmet> but we decided some big changes in it so I'll get back to it
to stick to what we decided
15:07 < gsmet> #topic Next 2 weeks Guillaume
15:08 < gsmet> so hopefully mostly Search 6 with some ORM coordination
15:08 < gsmet> I say that every 2 weeks so we'll see
15:08 < gsmet> FYI, PTO for me starting Sept 14th
15:09 < gsmet> for a week
15:09 < gsmet> #topic Progress Yoann
15:09 < yrodiere> So, I was on PTO the first week
15:09 < yrodiere> Good progress on the babysitting side
15:09 < yrodiere> then it was the F2F
15:09 < yrodiere> No, I won't say it was babysitting too :)
15:10 < yrodiere> Joke aside, we actually made good progress, took lots of
decisions on pending topics
15:10 < fax4ever> :)
15:10 < yrodiere> and actually managed to cover the whole agenda
15:10 < yrodiere> so... It means there's a lot more to work on now than
before. Which I guess is good news :)
15:11 < yrodiere> I won't cover the specifics, but I'm currently organizing
everything as JIRA tickets
15:11 < yrodiere> see
https://hibernate.atlassian.net/login?dest-url=%2Fprojects%2FHSEARCH%3Fse...
15:12 < yrodiere> so, next two weeks
15:12 < gsmet> #topic Next 2 weeks Yoann
15:12 < yrodiere> there are still a few tickets, mainly refactoring, to
address, and then we should be able to merge the Search 6 prototype into
the main Search repository
15:13 < yrodiere> that should be the big news of the next two weeks...
hopefully.
15:13 < yrodiere> after that there is still a bit of polishing to do, and
we should be able to release an Alpha1 in one or two months at most
15:14 < yrodiere> then I hope we'll be able to follow a more...
"high-paced" rhythm, to provide sneak peaks into the current work to our
users
15:14 < yrodiere> that's all from me
6 years, 3 months
How to enable Javassist when running a WildFly unit test?
by Gail Badner
I tried running:
mvn clean test -Dtest=HibernateNativeAPINaturalIdTestCase
-Dhibernate.bytecode.provider=javassist -Dsecurity.manager=true
The result is a permissions failure, and ByteBuddy is in the stacktrace.
I also tried adding the property to the StandardServiceRegistryBuilder
built by SFSBHibernateSFNaturalId, and that didn't work either.
Is there some other way to enable javassist?
Thanks,
Gail
6 years, 4 months
Returned mail: Data format error
by Bounced mail
The original message was received at Mon, 27 Aug 2018 15:37:37 +0800
from lists.jboss.org [15.9.202.182]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
6 years, 4 months
Please do not merge to ORM 5.3
by Guillaume Smet
Hi,
Please do not merge anything to ORM 5.3 for now, we need to have a
discussion about what we merge there.
Thanks!
--
Guillaume
6 years, 4 months
BlobProxy, Reducing the amount of Proxies we rely on at runtime
by Sanne Grinovero
I'm trying to understand if we could remove some of the usages of
`java.lang.reflect.Proxy`.
Clearly it's a long journey and maybe we will never be able to remove
them all, but I would at least want to try avoiding most of their neet
at runtime - limiting their usage at bootstrap/configuration or other
similar "one time" contexts.
We're all aware that these proxies have not been introduced lightly:
most are necessary or very useful; at least useful enough to prefer
having them to not having them; surely the tradeoffs have been
considered.
So what I'm trying to understand now is if all the tradeoffs made in
the past are still actual; some of the related code is > 10 years old;
I could use some help with evaluating what could be safely removed.
One example: org.hibernate.engine.jdbc.BlobProxy has the following comment:
"We use proxies here solely to avoid JDBC version incompatibilities."
Today we require Java8 as baseline, and the `java.sql.Blob` did not
change in any more recent JDK (I just thouroughly diff-ed the
JDK8,9,10,11,12 on this package using Gunnar's jdk-api-diff tool).
Would that be a reasonable candidate to replace the Proxy usage with a
plain implementation of the relevant interfaces? Clearly this implies
I'm betting that future JDKs will not break this again, still I'd
rather cleanup this usage today.
1 - Could I go ahead with that?
2 - Any more such cleanups come to mind?
Thanks,
Sanne
6 years, 4 months
Releasing Hibernate ORM 5.2.18.Final?
by Guillaume Smet
Hi,
So, it's been a long time since we last released the ORM 5.2 branch and
some people are asking about it, some of them with good reasons not to
upgrade to 5.3.
I think we are making it something big because we wanted it to be THE last
5.2 release and this ends up in it not being released at all.
Also, we have a lot of other things to do, which doesn't help.
I propose the following plan:
- starting September 1st, I'll go through the 5.3 fixes and see what can be
easily backported - we already have important fixes in 5.2.18 so if some
issue is not easily backportable or worth it, I'll skip it altogether and
wait for someone to complain vocally about it;
- I'll wrap up a 5.2.18 by September 14th;
- if we need one more after that, I'll do another release.
If you have a 5.3 fix you absolutely want in 5.2.x, please be vocal about
it because there's a good chance I will be pretty aggressive in not
backporting the bugfixes we pushed to 5.3 recently (e.g. not cherry-picking
gracefully -> not in 5.2.18).
The idea is to let Gail focus as much as possible on the still opened 5.1
-> 5.3 regressions.
Does everybody agree with this plan?
--
Guillaume
6 years, 4 months
