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 <st...@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.pand...@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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
