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*
6 years, 11 months
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?
>
>
>
7 years, 1 month
Property "ogm.datastore.create_database": fit for purpose?
by Sanne Grinovero
This property is defined in hibernate-ogm-core and while it's quite
self-explanatory with other NoSQL stores, it doesn't translate nicely
to the Infinispan scenario.
I'd be tempted to introduce ad-hoc properties for each Dialect so that
their effect is clear, allowing to pick more fitting names.
We also like to keep configuration properties to the minimun. In fact
I'd like to simply use Environment.HBM2DDL_AUTO to create / define
Caches ?
Conceptually in Infinispan they are closer to "tables" than
"databases", except they are all schema less and we deploy a schema
using a different operation..
Let the fight begin!
Thanks,
Sanne
7 years, 1 month
New layout for in.relation.to
by Guillaume Smet
Hi!
I converted in.relation.to to the new layout and pushed it to
http://staging.in.relation.to/ .
Please take a look at it so that we can make progress quickly.
Note that I still have some work to do on the mobile side. Will do once the
dust has settled and we agree on the layout.
The home page:
http://staging.in.relation.to/
The blog post page: the idea here is to just present the content in a very
minimal way:
http://staging.in.relation.to/2017/09/25/hibernate-community-newsletter-2...
While it's not validated, please be careful when cherry-picking your new
blog post to production, don't merge my commits by mistake!
Note that it doesn't change anything to the blog posts so business can
continue as usual and you can safely cherry-pick your blog post from
staging to production.
Looking forward to your feedback.
--
Guillaume
7 years, 1 month
ORM release process
by Guillaume Smet
Hi ORM guys,
So with a new website comes new responsabilities.
I updated the NoORM release process but I don't know where you put these
information for ORM.
So basically, when you release a new MAJOR version, you will have to take
care of adding a *data/projects/orm/releases/series.yml *file and a *orm*
*/releases/<version>/index.adoc* file.
Basically, you have to do the same thing for the release page than what you
already do with your custom documentation page.
We already created them for the existing releases so you already have
templates you just have to adjust when publishing a new major release.
--
Guillaume
7 years, 1 month
New layout for the website
by Guillaume Smet
Hi,
Following Yoann's work and based on it, I tried to work on a new layout for
the website.
The idea was to make it more modern while not starting a full discussion
about the content. I think we could benefit from making more iterative
improvements.
I know a few things bother some people to who I already presented this
work, but this is what I would like to present as "my proposal for a new
website".
I tried to take into account the remarks I found consistent with my vision
(which unfortunately prevents you to see my first ugly try at a new home
page, blame Sanne for that :)).
I didn't change the content (except for reorganizing a few links in the
menu to put "Source code" before "Wiki" for instance). That's not the point
of this exercise.
I added a short baseline on each About page. They are just placeholders,
better propositions very welcome!
The hero text below coming from the old site can also probably be tweaked
for the new layout.
Generally I think some changes are due to the content but that's for
another day and for another discussion.
To play with it:
http://new.hibernate.org/
with
54.174.65.136 new.hibernate.org
in your /etc/hosts
The branch on GitHub is "new-layout".
I consider the conversion work completed, so if you see any issue, it's not
normal, please report it.
The only thing I have in mind for the near future is to improve the mobile
experience but I think it can be kept as a second step. It's usable as of
now, even if not perfect.
--
Guillaume
7 years, 1 month
[Search and more] What is new in a give release
by Emmanuel Bernard
Hey all,
I was trying to answer the following question, what is roughly new between 5.6, 5.7 and 5.8 (minor releases)?
My first reflex was to go to http://hibernate.org/search/downloads/ <http://hibernate.org/search/downloads/> to read about the onliner per release. Except it’s a onliner per micro release and “minor adjustments” for 5.6.3.Final gave me literally no info whatsoever.
My second reflex was to go to http://hibernate.org/search/roadmap/ <http://hibernate.org/search/roadmap/> to find a historical entry about older versions and the main changes in bullet points. No luck. It only talks about the future.
My third reflex was to go to http://in.relation.to/hibernate-search/ <http://in.relation.to/hibernate-search/> I ended up giving up midway page 2 of the list of blog entries. It’s a mix of simultaneous parallel releases with what’s new since the last CR or the last micro kind of reports and gave up in dismay at the energy I would have to spend to extract what’s new for a full minor release.
I did exaggerate a bit the third point but I did give up. We need somewhere a summary page of what’s new per minor releases. I think the roadmap page could be the host.
Likewise, we might need a oneliner entry in the download section (per release) that points to this minor release summary.
Thoughts?
Speaking of roadmap:
- HV roadmap is massively out of date
- OGM is lying a bit on the future but at least has the past summary I was talking about
- Search has a good future roadmap but no past
Emmanuek
7 years, 1 month
Website - Remove the Google+ links
by Guillaume Smet
Hi,
We have a couple of Google+ links here and there on the website.
I was thinking we should probably remove them as they sound a bit 2010 and
I don't think we are actively maintaining it.
WDYT?
--
Guillaume
7 years, 1 month
Re: [hibernate-dev] [website] Specific series page
by Yoann Rodiere
So the order would be:
* Compatibility
* Documentation
* How to get it
* What's new
* Migrate
* Releases in this series (we just renamed it, I think it pretty much
solves the issue we were having)
Right?
Seems ok to me, no strong opinion about that. As long as compatibility info
stays at the top ;)
Anyone against it?
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
On 28 September 2017 at 09:42, Yoann Rodiere <yrodiere(a)redhat.com> wrote:
> So the order would be:
>
> * Compatibility
> * Documentation
> * How to get it
> * What's new
> * Migrate
> * Releases in this series (we just renamed it, I think it pretty much
> solves the issue we were having)
>
> Right?
>
> Seems ok to me, no strong opinion about that. As long as compatibility
> info stays at the top ;)
>
> Anyone against it?
>
>
> Yoann Rodière
> Software Engineer, Hibernate NoORM Team
> Red Hat
> yrodiere(a)redhat.com
>
> On 28 September 2017 at 09:20, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
>
>> And I am +1 to push the new style today. These discussions are not linked.
>>
>> > On 28 Sep 2017, at 09:17, Emmanuel Bernard <emmanuel(a)hibernate.org>
>> wrote:
>> >
>> > Hello
>> >
>> > Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor
>> proposals.
>> >
>> > In frequency, I think people go read the docs online much more than
>> they want to know how to get it. So I would put the Documentation section
>> at the top (or below the compatibility matrix if you won’t budge).
>> >
>> > In the natural flow of information discovery (I know it breaks my
>> argument above), I would put the What’s new before the migration section.
>> >
>> > I know we have been going on and off over "Older releases”, what it is,
>> is "Previous micro releases". So how about using that title. I imagine
>> every one will understand.
>> >
>> > Emmanuel
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
7 years, 1 month
