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