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
>>
>
>
8 years, 2 months
[website] Specific series page
by Emmanuel Bernard
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
8 years, 2 months
Too simple a solution for HHH-11147 ?
by Thomas Reinhardt
Hello,
I investigated HHH-11147 (Allow enhanced entities to be returned in a
completely uninitialized state) and have a very small fix for that issue.
I want your feedback if I am going the correct route here. Seems too
easy and lazy loading is a pretty important piece of hibernate.
To spare everyone opening the issue just to get an overview here is a
short summary:
The use case is an entity with a simple relation:
@Entity
@Proxy(lazy=true)
class MyEntity {
@ManyToOne(fetch=FetchType.LAZY)
OtherEntity other;
}
Both entities are bytecode enhanced at compiletime with
enableLazyInitialization=true. The problem is that the "other" entity is
fetched despite being annotated as lazy.
My quick fix is actually only two changed lines. A proper diff
(HHH-11147-quick-and-dirty.diff) is attached to the issue. I did
specifically not make a PR just for this discussion but if requested I
can of course make one. A pseudo-diff can be found below.
I did test this fix on our main application and it seems to work. There
are two main questions:
1) could there be cases where we create a proxyFactory without need?
2) am I killing the benefits of the bytecode enhancement by using a
proxy or do I still get things like association handling?
Sorry for the wall of text but I thought this discussion does not belong
in the issue itself. Correct me if I am wrong.
Greetings,
Thomas
Pseudo-diff:
org.hibernate.event.internal.DefaultLoadEventListener
proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadType) {
...
// this class has no proxies (so do a shortcut)
- if ( !persister.hasProxy() ) {
+ if ( !persister.getEntityMetamodel().isLazy() ) {
return load( event, persister, keyToLoad, options );
...
}
org.hibernate.tuple.entity.AbstractEntityTuplizer
public AbstractEntityTuplizer(...) {
...
instantiator = buildInstantiator( entityMetamodel, mappingInfo );
- if ( entityMetamodel.isLazy() &&
- !entityMetamodel.getBytecodeEnhancementMetadata()
- .isEnhancedForLazyLoading() ) {
+ if ( entityMetamodel.isLazy() ) {
proxyFactory = buildProxyFactory( ... );
...
}
8 years, 2 months
JVM metadata costs vs the use of inheritance across Logger interfaces
by Sanne Grinovero
Our friend and colleague Andrew Dinn from the OpenJDK team is working
on a series of blog posts to help people understand the impact of
certain design choices on the cost of internal JVM metadata and native
memory; this affects bootstrap costs of both the JVM and our
libraries, overhead at runtime in terms of permanent memory waste,
etc..
So as these blogs will be out soon I'm not going to dive into more
details or how I discovered this, but as a draft reviewer I had the
privilege to already play with the technique and send a PR to
Hibernate Search as result of verifying some theories.
In a nutshell Andrew's work allowed me to spot that having a Logger
interface in module A extended by another Logger in module B is
causing it to generate a significant amount of duplication of Class
definition metadata: the generated loggers are quite verbose in terms
of such costs and don't benefit from inheritance as one would expect:
the cost of B is (A+B), if you ignore benefits from symbol
de-duplication. In this specific example I could measure more than
200K of wasted space. That's not small for a single jar! Incidentally
in this case it also bloats the jar file size.
A code patch might be more clear to explain than emails; this is what
I recommend we do in all projects:
- https://github.com/hibernate/hibernate-search/pull/1546
N.B. the verbosity of the generated code is related with runtime
performance so I don't think we'll to remove the generated Logger
metadata, and certainly don't plan to switch logger implementations as
there are many more aspects to take into account - yet we might have
identified an anti-pattern which is multiplying this cost N times
without a good reason and it's quite easy and under our control to
avoid that.
Thanks,
Sanne
8 years, 2 months
Number of SQL statements
by Thomas Reinhardt
Hello Hibernate Team,
is there a good way to check in a junit test which number of sql
statements are generated ?
I want to tackle some of the lazy loading/class enhancement issues and
those need good tests of course.
Somehow related: I have a (rather trivial) fix for HHH-7842 (Hibernate
Criteria does not respect fetch mode, when alias is used). As this is
related to the now deprecated Hibernate Criteria API is there any chance
my fix gets accepted or should I spare my time?
Thanks,
Thomas
8 years, 3 months
New `noorm-admins` team on Github & proposal for group restructuring
by Sanne Grinovero
I created a new team on Github and am giving it admin privileges to
Validator, Search, OGM, and the related support repositories (JPQL
parser, HCANN).
This is to give some selected members admin privileges on the
repositories; useful as it allows us to "proctect" branches when we
create maintenance release branches, which is becoming routine so I
shouldn't be the only one with such privileges.
It also allows all members to delete repositories and/or to
temporarily remove such protection in case of extreme need. Needless
to say, I expect some kind of quorum among us - in writing on this
mailing list - before taking any such initiatives!
We already had an Admin team but I'm no longer comfortable in using a
single Admin team for all 30+ repositories, it requires giving too
many privileges to too many people.
The single admin team is a legacy of how GitHub used to work in the
past; let's disband it and replace it with more fine grained groups?
Thanks,
Sanne
8 years, 3 months
