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 delega
Ok, silence will be taken as a vote to do whatever I feel is best
regardless of impact on these integration impls... So anyone?
On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole wrote:
> Last night I pushed some changes which included deprecating
> org.hibernate.cfg.Settings in favor
> of org.hib
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
As long as we can explicitly disable things via API like we could in
past this should be fine.
i.e. in tools we used setting properties to disable second level
caching, hibernate validator, connection pooling, tx management and
search setup since it just doesn't either make sense or won't work
That's really more a function of bootstrapping, not the actual Settings
object. And yes, these hibernate.properties et al are still picked up and
used.
On Tue, Apr 21, 2015 at 4:14 PM, Max Rydahl Andersen
wrote:
> As long as we can explicitly disable things via API like we could in past
> this
Har
On Tue, Apr 21, 2015 at 1:52 PM, Hardy Ferentschik
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
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
MetadataBuilderInitia
> On 21 Apr 2015, at 20:52, Hardy Ferentschik wrote:
>
> 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
