[hibernate-dev] org.hibernate.cfg.Settings deprecated

[Hardy Ferentschik]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev