6.0 - design question: "model navigation" exposed as an API?
by Steve Ebersole
Currently in 6.0 we have the notion of a Navigable which models any "piece"
of the application's domain model[1]. We also have the notion of
a NavigableVisitationStrategy which defines the strategy for handling the
visitation of the nodes in a Navigable tree. In other words, Hibernate
defines a common visitor for how to walk the application's mapped domain
model and the NavigableVisitationStrategy implementation controls which
sub-trees are walked; e.g. we'd use this to apply JPA EntityGraphs or to
stop joining joinable Navigables after we have reached the
`max_fetch_depth` setting value.
It is important to note that this is very, very different from JPA's model
and walking it. JPA's model essentially precludes those model nodes from
defining relational mappings as part of its type system in any sane way;
this is due to various reasons because of the model's design[2]. This
Navigable walking would walk the real/full relational mapping model.
The design question is whether we want to expose this "domain mode walking"
as a general public API feature. This has been requested before; Max once
asked for it although I forget why.
Making this an API means exposing quite a few things. Typical visitor
pattern, the visitor (NavigableVisitationStrategy) exposes "handle" methods
based on specific Navigable sub-types. Those sub-types would need to be
moved to API. I don't have a particular concern with that, just mentioning
it.
Opinions on whether this should become an API?
For sure we'd mark it @Incubating, if we decide to do it.
[1] Short synopsis: Navigables include things like EntityPersister,
CollectionPersister, EmbeddedPersister, PersistentAttribute,
CollectionIndex, CollectionElement. A Navigable is always relative to a
NaviagbleSource. NaviagbleSources are any domain Navigable
(NavigableSource extends Navigable) which includes things like
EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
CollectionElementEntity, CollectionElementEmbedded, etc . The
NaviagbleSource will be null in the case of EntityPersister (as a root),
but in all other cases the NaviagbleSource is non-null.
[2] I won't get into the reasons here, but we can certainly follow up if
anyone challenges that assertion.
9 years
Hibernate#isPropertyInitialized vs Hibernate#isInitialized
by Gail Badner
I think there can be an inconsistency between
Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
an extra-lazy collection of an enhanced entity.
IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
on an enhanced entity, the collection property is set to an uninitialized
PersistentCollection and calling Hibernate#isPropertyInitialized(
collectionfieldName ) will return true, even though the collection itself
is uninitialized.
I would have expected that false would be returned.
I've added a comment to the issue and asked Luis about it. Luis has pointed
out the 3 stages of an extra-lazy collection on an enhanced entity. I've
listed them below and added my understanding of what Hibernate#initialize
and Hibernate#isPropertyInitialized will return in each instance:
1) the attribute is not loaded at all;
Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns false;
Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
false; a side-affect
is that the attribute will be set to an uninitialized
PersistentCollection.
2) the attribute is loaded, but the elements are not loaded;
Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns true,
because the property is initialized to a PersistentCollection (even
though the PersistentCollection itself is uninitialized).
Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
false.
3) the attribute is loaded and the elements are loaded.
Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
returns true.
Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
true.
Opinions about the inconsistency in 2)? Is this a bug in the code or in the
Javadoc?
Thanks,
Gail
[1] https://hibernate.atlassian.net/browse/HHH-11161
9 years
[OGM] WildFly modules imposing versions
by Emmanuel Bernard
I’ve upgraded the OGM demo to OGM 5.1 Final (from CR1).
Again I’ve got deployment errors because it does not find the specific search version: 5.6.1.Final. I had 5.6.0.Final in my WF module deployment.
Is that the behavior we want? Do we want the OGM module to impose specific versions of Hibernate Search to work? I don’t even use Hibernate Search for the demo…
How can we improve things?
Emmanuel
9 years
Hibernate OGM 5.1 Final is out
by Davide D'Alto
I’m happy to announce the latest stable release of Hibernate OGM:
Hibernate OGM 5.1 Final
== What’s new compared to 5.0 Final?
I’m glad you asked, this version:
- uses Hibernate ORM 5.1
- supports Infinispan Remote via the Hot Rod protocol
- supports Neo4j remote via the Bolt protocol and the Http interface
- can integrate with Hibernate Search 5.6, which works with Elasticsearch
- reduces the number of database calls by grouping the operations
- supports aggregation in MongoDB native queries with CLI syntax
More details in the blog post:
http://in.relation.to/2017/03/02/hibernate-ogm-5-1-Final-released/
Thanks,
Davide
9 years
Re: [hibernate-dev] introduction newbie
by Sanne Grinovero
Hi Vaibhav,
welcome, I'm glad you want to help with Hibernate Search!
But I'm afraid we don't maintain diagrams of the internal architecture. I
would suggest to start getting familiar with it by using it, and trying to
figure out how it works by debugging, writing tests or exploring the source
code. Using it in a project you work on is usually very effective as well.
The code base is quite large so I would not suggest to try reading it all.
A good approach could be to try fixing a simple issue - you can find many
open tasks on our JIRA - by writing a unit test first and then trying to
figure out how to create a fix for it.
This is a list of open JIRA issues which we *think* might be a good
starting point for developers new to the project:
- https://hibernate.atlassian.net/issues/?filter=11250
When you think you have a great patch to share send a pull request (make
sure to include tests, javadoc and documentation changes if any are
necessary).
Some other person will eventually volunteer to review your changes, and
possibly suggest improvements or give you other advice based on their
longer experience with the project. It's possible your pull request will
require improvements or not be merged, but there's nothing to be ashamed of
we all learn that way.
Thanks,
Sanne
On 1 March 2017 at 12:39, vaibhav kulkarni <vcharmcaster(a)gmail.com> wrote:
> Hello Sanne,
>
> Vaibhav Khamgavkar( VK ) is newbies name, Hibernate Search grabbed my
> attentions.
> Will like to contribute to this project. can you send me high level
> design/ architecture diagram?
> in case you are not right person to contact let me know whom should i
> contact.
>
>
>
> --
>
>
> [image: --]
>
> Vaibhav Khamgonkar
> [image: http://]about.me/vaibhav_khamgonkar
> <https://about.me/vaibhav_khamgonkar>
>
>
> Note: This e-mail message and attachments may contain confidential
> information. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message.
>
9 years
