redesign SessionFactory building
Description
depends on
is a fix for
relates to
required for
Activity
Steve EbersoleMay 2, 2011 at 6:12 PM
Finalize design
Steve EbersoleApril 24, 2011 at 3:53 PM
Calling this done. Any specific tweaks to the API should be specific JIRA issues at this point. The API is currently:
org.hibernate.service.BasicServiceRegistry registry = new org.hibernate.service.ServiceRegistryBuilder()
.configure() // similiar to legacy Configuration#configure
.applySetting( AvailableSettings.SHOW_SQL, "true" ) // similar to legacy Configuration#setProperty
...
.addService( ... ) // adds a specific service instance for transfer to the built registry
.addInitiator( ... ) // adds a service initiator for transfer to the built registry
...
.buildServiceRegistry();
SessionFactory sessionFactory = new MetadataSources( registry )
.addResource( "some.hbm.xml" )
.addAnnotatedClass( AnEntity.class )
...
.buildMetadata()
.buildSessionFactory();One tweak that is being discussed is adding a notion of "metadata builder" to apply stuff like NamingStrategy etal that are only "in effect" for the duration of the metadata building. A proposed API there:
SessionFactory sessionFactory = new MetadataSources( registry )
.addResource( "some.hbm.xml" )
.addAnnotatedClass( AnEntity.class )
...
.getMetadataBuilder()
.setNamingStrategy( ... )
...
.buildMetadata()
.buildSessionFactory();Steve EbersoleApril 24, 2011 at 3:38 PM
Justin, as a follow up, depending on your exact need you might be interested in the new feature of "SQL type remapping" from the Dialect. See the new org.hibernate.dialect.Dialect#remapSqlTypeDescriptor method.
I also proposed a new idea to the hibernate-dev mailing list that would allow Dialects to contribute/override the Types used in a SessionFactory -> http://lists.jboss.org/pipermail/hibernate-dev/2011-April/006342.html
Steve EbersoleApril 16, 2011 at 10:16 PM
The initial proposal for this API is:
// BasicServiceRegistry is the set of general purpose services. Users
// can override built-in services, add additional services or completely
// provide the set opf services (BasicServiceRegistry is an interface).
BasicServiceRegistry registry = ...;
// Next, we tell Hibernate about Object/Relational metadata
MetadataSources metadataSources = new MetadataSources( registry )
.addResource( "a.b.c.SomeMapping.hbm.xml" )
.addAnnotatedClass( a.b.c.SomeEntity.class );
SessionFactory sessionFactory = metadataSources.buildMetadata().buildSessionFactory()Steve EbersoleMarch 30, 2011 at 3:43 PM
Since it really needs the finished work on
Details
Assignee
Steve EbersoleSteve EbersoleReporter
Steve EbersoleSteve EbersoleTime tracking
0.55h loggedComponents
Fix versions
Priority
Critical
Details
Details
Assignee
Reporter
Time tracking
Components
Fix versions
Priority
Critical
Currently a SessionFactory is built by throwing a bunch of stuff into a Configuration object, stirring it, letting it come to a boil, and then pulling out the SessionFactory. In seriousness, there are a few problems with the way we currently operate within a Configuration and how we use it to build a SessionFactory:
The general issue that there is no "lifecycle" to when various pieces of information will be available. This is an important omission in a number of ways:
1) consider schema generation. currently we cannot even know the dialect when a lot of db object names are being determined. this would be nice because it would allow us to transparently handle table/column names which are also keywords/reserved-words in the dialect, for example.
2) static-ness of types and the type-mappings. Because we currently have nothing to which to scope them. Ideally a type instance would be aware of the SessionFactory to which it is bound. Instead, what we have now is to change API methods quite a lot of the time to add in the SessionFactory as a passed parameter whenever it is discovered that it is needed.
3) also, most (all?) of the "static" configuration parameters in Hibernate are currently required to be so because of their use from within these static types; thus scoping types would allow us to also scope those config parameters (things like bytecode-provider, use of binary streams, etc).
Ideally what I see happening is a scheme where users build a org.hibernate.cfg.Settings (or something similiar) instance themselves. Additionally they would apply metadata to a registry of some sort (lets call it MetadataRegistry for now). Then in order to build a SessionFactory, they would supply these two pieces of information (via ctor? via builder?). The important aspect though is that the information in MetadataRegistry would not be dealt with until that point in time, which would allow us to guarentee that resolving schema object names, types, etc would have access to the runtime Settings (and specifically the dialect)