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

[Steve Ebersole]

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 at 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 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
>