Re: [hibernate-dev] org.hibernate.cfg.Settings deprecated
Hardy,
Settings still has that method. I also had to expose that from
SessionFactoryOptions, and Settings delegates to that.
Long term, I am not sure. Obviously I dislike the setters here. Maybe a
good case for adding a SessionFactoryBuilderInitializer (along the lines of
MetadataBuilderInitializer). We would have a
SessionFactoryBuilderInitializer for trhe validator integration that would
initialize this setting based on whatever it bases calling the setter now.
Users would still be able to override that directly via the
SessionFactoryBuilder.
On Tue, Apr 21, 2015 at 1:52 PM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
On Tue, Apr 21, 2015 at 01:09:53PM -0500, Steve Ebersole wrote:
> Ok, silence will be taken as a vote to do whatever I feel is best
> regardless of impact on these integration impls... So anyone?
Sorry, I forgot about this one. TBH, I have not much useful to say on
what the best way to do this is. It seems to make sense to disable ORM
based
null checking if Bean Validation is used (even though Emmanuel wrote this
code
initially. I am not 100% which kinds of scenarios this tries to prevent.
My guess
is that when this option is enabled and Bean Valdation's @NotNull
is used as well, the ORM validation kicks in first and throws some ORM
specific exception
instead of the ConstraintViolationException one would expect in this case).
So whatever you come up with, I would expect some possibility for the
integrator to make sure
ORM null checking is disabled.
--Hardy
>
> On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve(a)hibernate.org>
wrote:
>
> > Last night I pushed some changes which included deprecating
> > org.hibernate.cfg.Settings in favor
> > of org.hibernate.boot.spi.SessionFactoryOptions. The main reason for
this
> > was to make it easier for OGM and others to hook into the
SessionFactory
> > creation process. For now, I have made Settings delegate
> > to SessionFactoryOptions.
> >
> > I am not sure if anything external relies on this Settings contract.
But
> > there are a few usages I wanted to discuss.
> >
> > First is caching. Part of the SPI for building RegionFactrory is
passing
> > along the Settings object. Ideally I'd just swap this with
> > SessionFactoryOptions. And given that this targets a major release
(5.0),
> > that should be ok. Anyone against that? Sanne? Galder? Alex?
> >
> > Second is the initiation of BV integration. The TypesafeActivator
> > accesses the Settings object in order to
> > call org.hibernate.cfg.Settings#setCheckNullability. As of now, this
is
> > the only setter method I have left on Settings (it simply passes that
call
> > on to the SessionFactoryOptions, which exposes just this one setter for
> > just this one case). I'd like to make it so that
SessionFactoryOptions is
> > immutable at the time SessionFactory is built. This was largely true
for
> > Settings already aside from this one use case. I am just not sure yet
of
> > the best way to allow an Integrator to affect this
SessionFactoryBuilder
> > process. Thoughts?
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev