Re: [hibernate-dev] Support for entities without default constructor

[Gunnar Morling]

I like it, but I think that's two separate concerns:

* using byte code generation to improve performance of entity instantiations
* avoiding the need for entities to have a parameterless constructor,
emphasising the mandatory properties of an entity (by requiring them as
constructor parameters) and allowing read-only entities to be truly
immutable (i.e. with final fields)

Both can be addressed independently.

The latter seems more impactful for developer experience, the need for a
default constructor has been a long-standing point of criticism often
raised by DDD-minded folks. As said on Twitter, it'll likely require an
annotation to mark the "persistence constructor", i.e. the one to be called
by Hibernate in case there are multiple ones. And we need a mapping between
parameter names and entity property names. That's "for free" if parameter
names are part of the byte code as possible with the "-parameters" option
in javac 8, otherwise some help by the developer is needed.

The avoidance of reflective constructor invocation via byte code generation
should be rather simple using ByteBuddy.

--Gunnar

2018-02-04 8:34 GMT+01:00 Vlad Mihalcea :

> For anyone interested, Josh Long tell more about why they took this
> approach where they inject the default constructor:
>
> https://twitter.com/starbuxman/status/960049941916696578
>
> Rafael Winterhaler shows that this can be easily done with Byte Buddy which
> we already used before:
>
> https://twitter.com/rafaelcodes/status/959892398997458946
>
> If we can prove that it's indeed significantly faster than using Java
> Reflection to build entities,
> I think we should think about taking this approach as well.
>
> What do you think of this?
>
> Vlad
>
> On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea 
> wrote:
>
> > Hi,
> >
> > I realized that we could allow users to define entities without a default
> > constructor.
> >
> > For Kotlin, which supportsdefault values, this could be beneficial.
> >
> > There is some info about how we could do that in this using Objenesis in
> > the following Spring issue:
> >
> > https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594
> >
> > Let me know what you think,
> > Vlad
> >
> ___
> 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] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

[Gunnar Morling]

Hi,

If the JPA validation mode is set to CALLBACK, BV constraints such as
@NotNull, @Size etc. are not reflected in the DDL created by ORM.

Instead, in TypeSafeActivator, the BV constraints are only considered for
DDL if the validation mode is DDL or AUTO [1].

CALLBACK is the safe way to ensure BV is invoked by JPA (instead of
silently ignoring it if no BV provider is present), so it's the setting I
usually recommend. I think constraints should also be propagated to DDL in
this mode, so I'm wondering whether there a specific reason for the current
behaviour or wether we can change it?

Thanks,

--Gunnar

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cfg/beanvalidation/TypeSafeActivator.java#L146
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev