HHH-10162 Inheritance and L2 cache
by Christian Beikov
Hey guys,
Steve said I should start a discussion about the possible solution for
HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we go.
While debugging the issue, I found out that the proxy is created at
DefaultLoadEventListener.createProxyIfNecessary() where it IMO should
consult the 2L cache first by calling existing =
loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks
easy, but I am not sure of the implications. Obviously this will affect
performance a little since it has to consult the L2 cache now.
I tried to start a discussion in the Dev room, but so far only Andrea,
Vlad and Chris have commented this. Has anyone a different idea for
implementing this?
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
7 years, 10 months
Fwd: You're on the Stride waitlist!
by Steve Ebersole
I've signed up for a "test drive" account on Atlassian's Stride server.
Stride is their replacement for HipChat.
---------- Forwarded message ---------
From: Stride by Atlassian <help(a)stride.com>
Date: Tue, Oct 24, 2017, 1:32 PM
Subject: You're on the Stride waitlist!
To: <steve(a)hibernate.org>
[image: Stride by Atlassian]
Nice! You're on the list!
[image: Stride waitlist]
Thanks for your interest in Stride!
What is Stride?
Stride is a complete communication solution that empowers teams to talk
less and do more. Stride provides teams with group messaging, video
meetings & built-in collaboration tools. We are rolling Stride out during
our Early Access Program and very excited for you and your team to try it!
When will I get on Stride?
When it's your turn, we'll reach out again to get your team started. You'll
be able to create a new team or upgrade an existing HipChat team. Get
answers to most of your questions on our FAQs
<https://confluence.atlassian.com/display/STRIDE/Stride+documentation?&utm...>
.
Thanks for your support! We can't wait to see your team hit its stride.
Cheers,
The Stride Team
Copyright 2017 Atlassian Pty Ltd. All rights reserved. We are located at 341
George Street, Sydney, NSW, 2000, Australia
<https://maps.google.com/?q=341+George+Street,+Sydney,+NSW,+2000,+Australi...>
Don't want to receive amazing emails from us? Unsubscribe
<https://i.prefinery.com/projects/ykmtf4f9/users/be9ecc46-2b3d-4352-a542-5...>
8 years
JDK 8u162 b01 Early Access is available on jdk.java.net
by Rory O'Donnell
Hi Sanne,
*JDK 8u162 Early Access* build 01 is available at : - jdk.java.net/8/
<http://jdk.java.net/8/>
Information and schedules specific to OpenJDK 8u162 release are listed
here <http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
<http://openjdk.java.net/projects/jdk8u/releases/8u162.html>
*JRE and JDK Cryptographic Roadmap* has been updated the details are
here <https://www.java.com/en/jre-jdk-cryptoroadmap.html>
**
*JavaOne2017* took place October 1 to 5, 2017 at San Francisco.
If you were unable to attend the event or missed some talks, below you
will find links to keynotes from last week
that have been posted for on-demand replay:
* JavaOne Opening Keynote (Monday, Oct. 2):
o https://www.oracle.com/javaone/on-demand.html?bcid=5596229112001
* Oracle Code Keynote (Tuesday, Oct. 3):
o https://www.oracle.com/javaone/on-demand.html?bcid=5600354378001
* JavaOne Community Keynote (Thursday, Oct. 5):
o https://www.oracle.com/javaone/on-demand.html?bcid=5604479599001
Regards,
Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years
Bugfix releases for Hibernate Search 5.6, 5.7 and 5.8
by Yoann Rodiere
Hi all,
We just published three bugfix releases of Hibernate Search: 5.6.4.Final
and 5.7.3.Final and 5.8.2.Final.
Please see the blog for more details: http://in.relation.
to/2017/10/26/hibernate-search-5-6-4-and-5-7-3-and-5-8-2/
Thanks,
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
8 years
SynchronizationRegistry: expose read (lookup) operations?
by Sanne Grinovero
Hi Steve,
do you think it would be sensible for me to explore introducing some
kind of synchronization lookup method on
org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
Today it only exposes a `registerSynchronization` method, which we use
extensively, but then we also have quite some complexity in the Search
code caused by the fact that we can't look the synchronizations up in
a later phase.
Essentially our Synchronization is stateful and we need to update it later.
I'd love to propose a change for ORM6 so allow registering such things
under some kind of id (a string?) so that one can look them back.
current SPI:
public void registerSynchronization(Synchronization synchronization)
temptative proposal (didn't try it yet..):
public void registerSynchronization(String id, Synchronization
synchronization);
public void Synchronization getSynchronization(String id);
does it sound reasonable in principle?
This would imply other users should make up an id unique for their use
case. Alternatively I could live with a Class used as an id, or we
could have the new methods in addition to the existing method for
people not interested in looking things up.
thanks,
Sanne
8 years
Programmatic entity mapping API
by Gunnar Morling
Hi all,
This has crossed my mind for a few times: should we provide a programmatic
API in Hibernate ORM for mapping entities, as an alternative mapping
definition source to annotations and XML? I.e. something similar to the
programmatic mapping APIs we have in Hibernate Validator and Search.
It'd probably be a fair bit of work (though giving lots of fun with API
design), but I can see how it could be appealing to folks preferring
API-style ways of configuring their stack, which seems more and more en
vogue these days. Using lambda expressions would be attractive especially
when it comes to plugging in custom behaviours, e.g. for value generators.
Any thoughts?
--Gunnar
8 years
Re: [hibernate-dev] Question..
by Steve Ebersole
I don't have the original email to reply to. So I'll reply here.
Overall, I had not really considered the primitive attribute case, but yeah
that's clearly an issue. My mistake.
A) I agree that the con here is huge. Not the best option
B) Is close to better. We could certainly check this and throw an error.
A better logical option is to do similar to what we do for ids and
versions... on startup instantiate one of these and grab/store its initial
state when freshly instantiated. We can later use those values to perform
the empty check. This is more logical, but not sure how "practical" it is
given that we do not really have a good place to keep this relative to an
embeddable, nor relative to an embedded, aside from CompositeType, but that
does not feel right. This is better in 6 as we have an actual runtime
model representation of the embedded and embeddable - but of course that
does not help us in 5
C) I really hate exposing `ComponentType` on a new SPI interface
considering the type system is completely revamped in 6. This would be (1)
a very short lived contract in this form and therefore (2) means yet
another pain point for user upgrading 5->6. Ultimately I think this is the
most promising solution moving forward (possibly coupled with the
"expanded" B option).. However, that said, I am not sure we have a choice
prior to 6 if we want to go this route - we'd have to expose the
CompositeType.. There is no good singular thing prior to 6 to describe a
embedded/embeddable. To clarify what sounds like a misunderstanding
though, CompositeType is unique to each embedded usage, not embeddable.
The CompositeType however does not expose its "role", so not sure if that
distinction helps here.
To make sure I understand your (D)... you mean to allow users to disable
this option globally but to allow this option per specific embedded?
Longer term (6) I think this is something else we ought to support as well
as the inverse (globally opt-in, but allowing a local opt-out). That's not
necessarily a strategy though for dealing with embeddeds that are
"opted-in" that happen to use primitives. Yes, it allows the user to more
actively and selectively manage that themselves, but if they happen to
opt-in an embedded which contains primitives we have the same issue to deal
with.
Longer term I see allowing a mix of (B) (expanded), (C) and (D).
For the short term (5), I think a the (possibly expanded) (B) option is the
best. I say that because (a) I prefer to not add a new contract like this
for a bug-fix release and (b) the concern about the immediate contract
change in 6. If we all deem that this is acceptable, I's be fine with (C)
as well.
On Fri, Sep 1, 2017 at 4:14 PM Gail Badner <gbadner(a)redhat.com> wrote:
> Hi Steve,
>
> No, I didn't hear back from you.
>
> I asked for a response to an email sent to hibernate-dev mailing list with
> subject, "HHH-11898: more "empty" composite issues".
>
> You can ignore the first message and just read the 2nd one.
>
> Thanks,
> Gail
>
> On Fri, Sep 1, 2017 at 12:53 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> You asked me to comment on an email, I'm sorry but I don't remember if I
>> did. Did I respond to you?
>
>
>
8 years
