How to contribute a driver?
by Ting Lou
Sorry to bother you all.
I'm writing a HBase driver for Hibernate OGM. Could anybody here tell me
what process I should follow?
Regards,
Ting
12 years, 9 months
metamodel branch and javax.persistence.metamodel.Metamodel
by Steve Ebersole
The background here is integrating my JPA 2.1 work in with the Hibernate
5.0 metamodel branch. One of the things the EntityManagerFactory does
when starting up is to build the JPA
javax.persistence.metamodel.Metamodel. Today that process leverages the
old Hibernate mapping code (org.hibernate.mapping). I will need to
re-write this to leverage the new org.hibernate.metamodel code. I
wanted to run the way I am thinking of attacking this past everyone to
get feedback. Basically I want to have the *SessionFactory* take over
responsibility for building it. 2 main reasons why:
1) First it would be more efficient. Today we loop over those mapping
objects at least twice: once to create the persisters as part of
SessionFactory building and then again later to build this JPA Metamodel
as part of EntiytManagerFactory building. Once is better than twice
when it comes to looping :)
2) I have this other idea where I'd really like to see JPA criterias
useable in "native" Hibernate usage (Session/SessionFactory). Which
would essentially require both javax.persistence.metamodel.Metamodel as
well as javax.persistence.criteria.CriteriaBuilder to be available.
Well technically any "criteria builder" that output the proper types
could work; and I guess Metamodel is not strictly needed to build
criterias aside from potentially populating the static generated
metamodel classes. But it would be nice to have them.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 9 months
Fwd: Re: Proxies and typing
by Steve Ebersole
Forwarding a part of this discussion that got inadvertently limited to
just Sanne and myself.
Bringing this back up because this is most likely not going to be
accepted into JPA 2.1. Anyway, I am all for going down the path that:
public interface User {
...
}
@Entity
@Proxy(proxyClass=User.class)
public class UserImpl implements User {
...
}
means that users would use User.class in all phases of the API:
User user = session.byId( User.class ).get( 1 );
EntityType<User> jpaEntityType = emf.getMetamodel().entity(User.class );
etc.
I think that is the cleanest path that allows generic-typed api.
-------- Original Message --------
Subject: Re: [hibernate-dev] Proxies and typing
Date: Thu, 26 Jan 2012 14:37:22 +0000
From: Sanne Grinovero <sanne(a)hibernate.org>
To: Steve Ebersole <steve(a)hibernate.org>
On 26 January 2012 14:02, Steve Ebersole <steve(a)hibernate.org> wrote:
> These emails are just between you and me. Not sure if thats what you
> intended. I erroneously replied to just you at one point but then sent to
> whole list also. Anyway, just mentioning...
Ah, sorry, didn't notice either. Well last reply then, will try resume
the public conversation if I have more comments.
> The idea of requiring the interface is appealing in a way. But, for
> example, there are odd inconsistencies then. For example
>
> User user = session.byId( User.class ).get( 1 );
>
> but then
>
> EntityType<UserImpl> jpaEntityType = emf.getMetamodel().entity(
> UserImpl.class )
>
>
> Which I guess is my biggest hang up. On one side we are saying that the
> impl is the entity and on the other saying the interface is the entity.
>
> You know me and consistency :)
I agree on consistency, but this is tricky, I'm not sure if you need
the UserImpl at all, maybe you can remove it from the MetaModel (maybe
after having read out other metadata from it).
Isn't such a mapping definition like a dirty workaround to actually
map the interface ?
Sanne
12 years, 9 months
Typing Help with JPA 2.1 impl
by Steve Ebersole
I need some help with generic types in the JPA 2.1 API, specifically
with regard to the new Join#on and Fetch#on methods. We ultimately
unify those 2 interface hierarchies into a single hierarchy in out code
using org.hibernate.ejb.criteria.JoinImplementor which extends from both
Join and Fetch.
The problem I am facing is in the return types. So, Join defines:
public interface Join<Z,X> {
public Join<Z,X> on(...);
...
}
Fetch defines:
public interface Fetch<Z,X> {
public Fetch<Z,X> on(...);
...
}
public interface JoinImplementor<Z,X>
extends Join<Z,X>, Fetch<Z,X>, FromImplementor<Z,X> {
...
}
The compiler does not at all like JoinImplementor as is, so I have to
override the method:
public interface JoinImplementor<Z,X>
extends Join<Z,X>, Fetch<Z,X>, FromImplementor<Z,X> {
public JoinImplementor<Z,X> on(...);
...
}
which should be fine as it is simple return type clarification. And
actually that definition compiles fine.
However, JPA also defines a whole hierarchy from Join such as.
CollectionJoin, ListJoin, etc. So Hibernate has for example:
public interface CollectionJoinImplementor<Z,X> extends
JoinImplementor<Z,X>, CollectionJoin<Z,X> {
@Override
public CollectionJoinImplementor<Z, X> on(...);
...
}
The IDE is fine with this type signature, however trying to compile this
leads to the following error:
types org.hibernate.ejb.criteria.JoinImplementor<Z,X> and
org.hibernate.ejb.criteria.JoinImplementor<Z,X> are incompatible; both
define on(javax.persistence.criteria.Predicate[]), but with unrelated
return types
I have no idea what I need to do here. Can anyone see the solution?
--
steve(a)hibernate.org
http://hibernate.org
12 years, 9 months
merge master into metamodel branch, again :)
by Strong Liu
Hi there,
I think we should do this again since there are some changes in master that I want to use in metamodel, and maybe we should do this regularly to minimize the conflicts?
Steve is the best to do this, since he already did this once, but in case he is busying on other stuff, I'm voluntarily to do this .
WDYT?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
12 years, 9 months
Re: [hibernate-dev] afterTransactionCompletion(status) in JtaTransaction
by Sanne Grinovero
Hi Steve,
thanks for the clarification.
Wouldn't it make sense then to add the "int status" as an argument to
afterAfterTransaction as well? As it seems some code looks for this by
invoking tx.getStatus() in implementations of this method, but that
seems unsafe as I've found cases in which this gets the wrong status
code at that point.
Sanne
On 18 July 2012 16:19, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
> afterAfterTransaction is simply a part of the afterTransaction process.
> afterTransaction is split into a number of steps, afterAfterTransaction
> simply being the last step in that process.
>
>
>
> On Wed 18 Jul 2012 05:15:20 AM CDT, Sanne Grinovero wrote:
>>
>> Hi all,
>> I'm puzzled about the implementation we have in
>> org.hibernate.engine.transaction.internal.jta.JtaTransaction
>>
>> regarding after-transaction completion handling.
>>
>> Looking at the two methods:
>> afterAfterCompletion(); <-- note the "After - After" prefix
>> afterTransactionCompletion(int status);
>>
>>
>> The implementation of afterTransactionCompletion(int status) is a
>> no-op, while after-after-completion actually invokes the
>> transactionCoordinator().afterTransaction( this,
>> userTransaction.getStatus() );
>> Shouldn't this be invoked in the afterTransactionCompletion(status)
>> method?
>>
>> As I just noticed in some OGM tests, during the after-after phase it's
>> too late to invoke the getStatus() on the transaction as this will
>> have been cleaned up already: that's why the
>> afterTransactionCompletion(int) has a status parameter, as the status
>> argument should be used rather than attempting to lookup the
>> transaction state again.
>>
>> OGM is having it's own AbstractTransactionImpl implementation;
>> changing it by moving the afterTransaction call in the appropriate
>> method fixed my problems to our Search integration.
>>
>> This looks like a change that should be picked up by ORM's
>> JtaTransaction too? I'm not familiar with this, so I might be totally
>> wrong but in case I would love to understand why.
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
12 years, 9 months
afterTransactionCompletion(status) in JtaTransaction
by Sanne Grinovero
Hi all,
I'm puzzled about the implementation we have in
org.hibernate.engine.transaction.internal.jta.JtaTransaction
regarding after-transaction completion handling.
Looking at the two methods:
afterAfterCompletion(); <-- note the "After - After" prefix
afterTransactionCompletion(int status);
The implementation of afterTransactionCompletion(int status) is a
no-op, while after-after-completion actually invokes the
transactionCoordinator().afterTransaction( this,
userTransaction.getStatus() );
Shouldn't this be invoked in the afterTransactionCompletion(status) method?
As I just noticed in some OGM tests, during the after-after phase it's
too late to invoke the getStatus() on the transaction as this will
have been cleaned up already: that's why the
afterTransactionCompletion(int) has a status parameter, as the status
argument should be used rather than attempting to lookup the
transaction state again.
OGM is having it's own AbstractTransactionImpl implementation;
changing it by moving the afterTransaction call in the appropriate
method fixed my problems to our Search integration.
This looks like a change that should be picked up by ORM's
JtaTransaction too? I'm not familiar with this, so I might be totally
wrong but in case I would love to understand why.
Cheers,
Sanne
12 years, 9 months
Design : delegates and constructors
by Steve Ebersole
Design question on how we want to handle this notion of delegates that
ogm, search, etc extend and constructors...
Specifically the notion that Sanne has asked for where ORM provides
implementations of stuff that OGM, Search, etc can just extend. So, for
example, AbstractEntityManagerImpl. AbstractEntityManagerImpl defines a
(what I call) "strict verbose" constructor. It takes 4 constructor
args. However, now take the case of JPA 2.1 where there is a new
argument (via new overloaded method) for EM opening (new
SynchronizationType enum) that we will need to pass along to the
constructor of AbstractEntityManagerImpl. This is where, IMO, this
concept of delegates starts to break down *as we generally define ctors
today*. IMO, for this notion of delegates to work as intended, I think
we needs to provide "bundled" constructor forms.
Again, taking AbstractEntityManagerImpl as the example, today we have:
protected AbstractEntityManagerImpl(
EntityManagerFactoryImpl entityManagerFactory,
PersistenceContextType type,
PersistenceUnitTransactionType transactionType,
Map properties) {
...
}
Leaving aside the passing of a Map for now...
What I think works best in terms of maintaining the intention of these
delegates is:
protected AbstractEntityManagerImpl(
AbstractEntityManagerImpl.Options options,
Map properties) {
...
}
or maybe even:
protected AbstractEntityManagerImpl(
EntityManagerFactoryImpl entityManagerFactory,
AbstractEntityManagerImpl.Options options,
Map properties) {
...
}
Where Options contains the things AbstractEntityManagerImpl needs to
initialize itself. Currently that would be 'type' and
'transactionType', but JPA 2.1 would add 'synchronizationType' as well.
The point though is that OGM, Search etc would not need to be changed
at all here if the constructor had been defined to accept
AbstractEntityManagerImpl.Options before and we added
'synchronizationType' in implementation of JPA 2.1.
Or is moving from JPA 2.0 to 2.1 going to warrant changes in OGM, Search
anyway that circumventing constructor signature changes is irrelevant?
--
steve(a)hibernate.org
http://hibernate.org
12 years, 9 months
JPA 2.1 progress
by Steve Ebersole
Just wanted to let everyone know that implementing JPA 2.1 support is
moving along. I had too much work here that I was worried about losing
so I went ahead and pushed it to my fork.
Draft 6 from the expert group is almost completely implemented at this
point. The only outstanding item left from Draft 6 is support for
"AttributeConverters" which I'll start on next.
If anyone wanted to start playing around with it or looking at it, like
I said, its pushed to my fork:
https://github.com/sebersole/hibernate-core/tree/jpa21
I went a slightly different approach with our shiny new native stored
procedure support compared to the JPA approach. The hope was to make it
easier to deal with the potential multiple interleaved
ResultSet/updateCount returns. Let me know if anyone has design
improvements there.
Subquery support on CriteriaUpdate and CriteriaDelete objects is still
undefined waiting for an updated spec addressing a problem there.
Other than that (and the AttributeConverter stuff) I fully expect this
to fully address Draft 6.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 9 months
