Re: [hibernate-dev] HHH-9440 Support for Java 8: parameter names
Nowadays the entity instantiation and data population is done like that:
final Object object;
if ( optionalObjectKey != null && key.equals( optionalObjectKey ) ) {
//its the given optional object
object = optionalObject;
}
else {
// instantiate a new instance
object = session.instantiate( instanceClass, key.getIdentifier() );
}
//need to hydrate it.
// grab its state from the ResultSet and keep it in the Session
// (but don't yet initialize the object itself)
// note that we acquire LockMode.READ even if it was not requested
LockMode acquiredLockMode = lockMode == LockMode.NONE ? LockMode.READ :
lockMode;
loadFromResultSet(
rs,
i,
object,
instanceClass,
key,
rowIdAlias,
acquiredLockMode,
persister,
session
);
What you propose is to delay the entity instantiation and create the entity
instance from after we have the hydrated state.
That's also the case for the second-level caching entries which must
"hydrate" an object instance.
The first problem is that JPA demands the default no-arg constructor:
"The entity class must have a no-arg constructor. The entity class may have
other constructors as well. The no-arg constructor must be public or
protected."
The property names that might be used as constructor arguments should
probably be annotated with a @ConstructorArg annotation and possibly
specify the argument order in the construction newInstance(args) invocation.
So, there are a lot of things to consider when implementing such a feature.
Vlad
On Mon, Mar 28, 2016 at 3:05 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
Commented on the Jira.
I am confused how you are "mind mapping" PreparedStatement parameters and
entity construction into the same conversation. We are not instantiating
entities based on PreparedStatement parameters....
On Fri, Mar 18, 2016 at 2:32 AM Lovro Pandzic <lovro.pandzic(a)gmail.com>
wrote:
> Hello,
>
> I'd like to discuss issue HHH-9440.
>
> Basic idea behind this issue is that we try to and eliminate the
> requirement for no arg constructor on entities or at least weaken that
> requirement to specific cases.
> Construction from both the user code and the hibernate itself would go
> through user specified constructors.
> This would enable use cases like enforcing invariants in constructors,
> immutable entities and in the long run, maybe even support for value
types
> coming in Java 10 that, at least for now, we know will be immutable and
> won't have a no arg constructor.
>
> By using parameter names and Java 8 API you can, for instance, map those
> parameter names to fields to find out column mappings and other
information
> required for mapping arguments to parameters.
>
> A similar approach like this is used by jackson-databind with the
> jackson-module-parameter-names (this will soon be integrated into the
> jackson-databind itself). Another example, Spring also uses parameter
names
> to map bean names to parameters in constructors.
>
> There are border cases like the one Steve mentioned in the issue:
>
> > How would you see lazy loading working then?
> >
>
> >From my perspective, there are 2 approaches here:
> - use a library like Objenesis that enables you to construct classes
> without using the constructor
> - document that all entities that are to be proxied must have a no arg
> constructor
>
> What do you guys think?
> _______________________________________________
> 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