[hibernate-dev] Building a SessionFactory

[Emmanuel Bernard]

My preference would go to a MetadataSources#setMetadata(NamingStrategy)

My fear is that more functions could be needed overtime and make the constructor or the buildMetadata signature cluttered and less readable. 


On 21 avr. 2011, at 15:08, Steve Ebersole wrote:

> NamingStrategy is not a service.  It is solely a function of building the metadata.
> 
> Currently, again, I have this set up via ctor param passing:
> 
> new MetadataSources( reg, new MyNamingStrategy() )
> 
> Really its not logically part of the source, its needed during the transition from source->metadata, so an alternative I have been contemplating is:
> 
> new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() )
> 
> I am open to other suggestions.  I really am trying to keep in mind the scope in which stuff is needed/useful/valid.
> 
> 
> On 04/21/2011 03:11 AM, Emmanuel Bernard wrote:
>> 
>> On 21 avr. 2011, at 05:43, Steve Ebersole wrote:
>> 
>>> I think this new API for creating a SessionFactory is starting to firm
>>> up, so I wanted to put out another call for feedback before we get too
>>> close to Alpha3.  So at a high level there are 2 pieces of information
>>> needed to build the SessionFactory: the ServiceRegistry and the Metadata.
>>> 
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> 
>>> The ServiceRegistry is built through a ServiceRegistryBuilder (this is a
>>> slight recent change)
>>> 
>>> Map config = ...;
>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( config )
>>>         ...
>>>         .buildServiceRegistry();
>>> 
>>> The "..." allows you to add service instances and service initiators.
>>> Currently any (map of) configuration values is passed in the
>>> constructor.  I can be convinced to allow adding/setting of config
>>> values as well, if everyone has a preference for that approach:
>>> 
>>> Map config = ...;
>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder()
>>>         .setConfigurationData( config )
>>>         .setOption( Environment.SHOW_SQL,
>>> true )
>>>         ...
>>>         .buildServiceRegistry();
>>> 
>>> Not sure the best method names there, to be honest which is why I opted
>>> for passing them to ctor.
>> 
>> Is that a Map<Object,Object>  or something a bit more refined?
>> 
>> Regardless of the map being passed to the ctor, I'd think you need to ability to set additional options (like you setOptions)
>> 
>> Alternative names:
>> option: setting
>> 
>> Not really related but, now that Configuration is gone, we lose some of the type safety (like cfg.setNamingStrategy(new MyNamingStrategy() ), or am I forgetting something in how the service registry works?
>> 
>>> 
>>> 
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> 
>>> Metadata is built through a MetadataSources which represents the sources
>>> of metadata information.
>>> 
>>> MetadataSources metadataSources = new MetadataSources( serviceRegistry )
>>>         .addResource( "some.hbm.xml" )
>>>         .addAnnotatedClass( SomeEntity.class );
>>> Metadata metadata = metadataSources.buildMetadata();
>>> 
>>> 
>>> 
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> 
>>> The Metadata is then used to obtain a SessionFactory.
>>> 
>>> SessionFactory sf = metadata.buildSessionFactory();
>>> 
>>> 
>>> Metadata represents the "configuration time" mapping information.  As of
>>> now we will allow users to manipulate and otherwise access this
>>> information, hence the seeming "intermediate step".  These all work with
>>> chaining:
>>> 
>>> SessionFactory sf = new MetadataSources( serviceRegistry )
>>>         .addResource( "some.hbm.xml" )
>>>         .addAnnotatedClass( SomeEntity.class )
>>>         .buildMetadata()
>>>         .buildSessionFactory();
>>> 
>> 
>> I guess you could have a buildMetadataSources() hosted on ServiceRegistry if you want people to use chaining methods all the way.
> 
> -- 
> Steve Ebersole <steve at hibernate.org>
> http://hibernate.org