Accessing metadata when SF is build the legacy way
by Koen Serneels
Hi. I'm digging up an older question
(https://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg12872.html)I
asked about modifying mapping metadata in H5. In short; I want to change the
mutability flag of mappings programmatically.
Using H4 there was a method called "getClassMappings" on
org.hibernate.cfg.Configuration. This method no longer exist in H5.
>From the previous answers/docu I understand that when using the new way of
building the SF one can interact with the metadata after building it using
the MetadataBuilder (but before building the SF) this would solve my
problem as I would be able to access the metadata at that point and change
the behavior.
Unfortunately, when using H5 through Spring4, the SF is built as what the
manual describes the "legacy way"; Spring's LocalSessionFactoryBean uses
Spring's LocalSessionFactoryBuilder which on its turn extends
org.hibernate.cfg.Configuration and calls org.hibernate.cfg.Configuration
#buildSessionFactory to build the SF.
Both metadata and sessionfactory are build in that single method leaving no
hook to modify the metadata.
At this point I don't see a normal/clean way in accessing the metadata
before the SF is build using the legacy way. So, am I missing something? Is
there maybe another way to access the metadata?
Thanks
Koen
9 years
Lazy attribute loading group support
by Steve Ebersole
Regarding HHH-10267...
5.1 will include a new feature allowing users to specify groups for
(bytecode enhanced) lazy attribute loading. In the original support
accessing one of these lazy attributes forced them all to be loaded[1].
For example...
@Entity
public class Company {
...
@Basic( fetch = FetchType.LAZY )
private String taxIdNumber;
@Lob
@Basic( fetch = FetchType.LAZY )
private Blob logo;
}
Once an application accessed any of the lazy attributes, they were all
loaded/initialized. So accessing `getTaxIdNumber()` would force `logo` to
be fetched as well. The new feature here is the ability to segment
attributes into different groups for lazy loading:
@Entity
public class Company {
...
@Basic( fetch = FetchType.LAZY )
private String taxIdNumber;
@Lob
@Basic( fetch = FetchType.LAZY )
@LazyGroup( "lobs" )
private Blob logo;
}
`@LazyGroup( "lobs" )` designates that `logo` is part of a specific fetch
group. Now, when the application accesses `getTaxIdNumber()`, `logo` is no
longer fetched at the same time.
P.S. A related question is this idea of
`(a)LazyToOne(LazyToOneOption.NO_PROXY)`. At the moment that is still needed
for "legacy reasons". The underlying reason is that we don't (didn't) know
when the to-one container is enhanced, so we rely on the user telling us.
I'd like to plan on dropping the requirement for the user to tell us this.
If they are using enhancement I am 99% certain they want NO_PROXY so it
seems redundant to make them tell us. Unless I am missing some use case.
Any thoughts?
[1] Technically the legacy bytecode enhancement treated collections
differently than other attribute types in this regard. The new enhancement
does the same as the default.
9 years
Jenkins
by andrea boriero
Am I wrong or Jenkins is not building anymore hibernate-orm?
9 years
Attribute laziness and caching
by Steve Ebersole
In reworking some of the support for bytecode-enhanced laziness, I started
thinking deeper about this idea of partial caching of such entities.
First and foremost, why do we even allow this? Essentially what happens is
that we allow a user to partially load an entity, and then stick that
partial state into the cache (along with a boolean indicating that the
state is partial).
I guess I can somewhat see the usefulness of this, but what really gets me
confused is how the caching of this data works.. As far as I can tell, we
never re-cache the entity state after the uninitialized portions have been
initialized. So the cached representation, iiuc, continues to be the
partial representation. If we continue to allow the partial representation
to be cached, wouldn't we want to update the cache entry with the
initialized portions once they become available?
9 years
(no subject)
by Steve Ebersole
I'd like to more formally deprecate the legacy bytecode enhancement
starting in 5.0.4 and remove it in 5.1.
The new code is superior and already feature compatible back to 5.0 Final.
Any objections?
9 years
Re: [hibernate-dev] Filter activation
by Steve Ebersole
Let's keep this on-list, please. Thanks!
The issue, to be clear, is not auto-enabling filters.. No, the
issues/concern is allowing enabled filters to be later disabled.
On Fri, Nov 13, 2015 at 8:34 AM Petar Tahchiev <paranoiabla(a)gmail.com>
wrote:
> Hello,
>
> I'm just chatting with the spring-boot guys now and they ask if hibernate
> allows you to specify the filters to activate in a property file. I guess
> they are interested in adding this functionality to spring-boot too.
>
> 2015-11-13 16:13 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> Well not sure I said it is valid ;) There are open questions such as the
>> one I brought up. For a proposal to be valid (as in possible) all such
>> questions need to have some answer.
>>
>> On Fri, Nov 13, 2015, 7:15 AM Petar Tahchiev <paranoiabla(a)gmail.com>
>> wrote:
>>
>>> Hi Steve,
>>>
>>> and thanks for your reply. I guess I have mis-understood what the real
>>> proposal was. Also, unfortunately I don't have enough knowledge of
>>> hibernate's internals and like you already mentioned this change will
>>> actually affect a lot of the code. My question was more to see what the
>>> hibernate team thinks about such a proposal, and if there was something
>>> totally against it. Now I know that it is a valid proposal and might be
>>> included one day in the pipeline.
>>>
>>> That's ok for me :)
>>>
>>>
>>>
>>> 2015-11-13 14:37 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>>>
>>> > Well I like this idea (additional flag on @Filter) better the actual
>>> > request (multi-valued config setting). And what about for the
>>> > @FilterDef(inition)?
>>> >
>>> > One concern I have is, e.g., getting a collection with a filter
>>> enabled,
>>> > now disabling a filter and then initializing the collection. That
>>> seems
>>> > like the outcome (the initialization will not be filtered) will not be
>>> what
>>> > was probably intended. Filters were designed to be disabled by
>>> default and
>>> > only enable-able; so a change like this will challenge assumptions
>>> > throughout the code.
>>> >
>>> > Is this something you are volunteering to work on?
>>> >
>>> >
>>> > On Fri, Nov 13, 2015 at 5:25 AM Petar Tahchiev <paranoiabla(a)gmail.com>
>>> > wrote:
>>> >
>>> >> Hello,
>>> >>
>>> >> here's a 6-year old issue:
>>> >>
>>> >> https://hibernate.atlassian.net/browse/HHH-3815
>>> >>
>>> >> That suggests to add another attribute on the @Filter annotation
>>> >> (something
>>> >> like activeByDefault=true). Can we have your oppinion on it?
>>> >> --
>>> >> Regards, Petar!
>>> >> Karlovo, Bulgaria.
>>> >> ---
>>> >> Public PGP Key at:
>>> >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> >
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>
9 years
Bytecode interception and attribute name versus attribute index
by Steve Ebersole
As I work on HHH-10267, a thought that keeps coming up in my head is that
it would be great to avoid Map lookups in the enhancement and interception
code.
As an example of what I mean, consider the reader for a String field named
`name` which roughly looks like:
public String $$_hibernate_read_name() {
return (String) $$_hibernate_getInterceptor().readObject( this, "name",
this.name );
}
In the interception code we need to resolve the attribute name ("name"
above) to the pertinent information from the persister,etc. Typically this
is a Map lookup; sometimes it is a done by iterating a String[] of the
attribute names.
Ultimately the information is taken from persister and friends, which means
that the information is generally already readily consumable via array
access once we have resolved the name to a proper index. Which got me
thinking it would be great if we could encode the attribute index into the
enhanced entity directly. Going back to the example about.. if we knew
that the "name" attribute was the 4th attribute (index=3) according to the
entity persister we could leverage that information for better performing
access to the attribute metadata in the enhanced code and interceptor:
public String $$_hibernate_read_name() {
return (String) $$_hibernate_getInterceptor().readObject( this, 3,
this.name );
}
One gotcha - always has to be one devil right ;) Ok, 2 really...
First, this obviously is more fragile than relying on names; if the order
changes but the bytecode is not re-enhanced, that could lead to very
subtle, nasty problems.
The other issue is that this requires us to be able to consistently be able
to order the attributes. The Enhancer currently does not rely on the built
metadata (org.hibernate.mapping) at all; it parses the entity annotations
(completely annotation specific) on its own. Given the 2-phase break down
in JPA bootstrapping, having Enhancer leverage the built metadata is not
really going to be possible. Which is unfortunate, because doing so would
be nice for other reasons (like supporting XML mappings for enhancement as
well, etc).
That's a lot of information, sorry about that :)
But anyone have thoughts on that?
9 years
Jira - GitHub sync
by Steve Ebersole
I have been noticing that the "GitHub link" in Jira is no longer
automatically performing syncs. I have asked Atlassian about it. In the
meantime, if you use that feature (commit linking, PR linking, etc) you
will have to manually force a sync in Jira
9 years
