[hibernate-dev] Building a SessionFactory

[Emmanuel Bernard]

I think we can converge by using the following approach.
https://gist.github.com/942450

Check the meeting logs, we have discussed the idea further.

BTW it occurred to me that MetadataSources is more a builder than anything else, should it be renamed to align with the service registry approach?

On 22 avr. 2011, at 20:43, Steve Ebersole wrote:

> I do not disagree, especially about the clutter.  I had two related concerns with that this approach though:
> 1) minor, but this thing is then no longer just collecting the sources of metadata which is what a MetadataSources is.
> 2) this is no longer a "directed API" at all.  What do I mean by that? Well:
> 
> MetadataSources sources = new MetadataSources(...);
> sources.setNamingStrategy( strategy1 );
> sources.addResource( "some/resource.xml" );
> sources.setNamingStrategy( strategy2 );
> sources.addResource( "some/resource2.xml" );
> 
> We are not "directing" the users to the correct usage of the API by the design of the API itself.
> 
> 
> Here is another option:
> MetadataSources sources = new MetadataSources(...)
>    ...
>    .getMetadataBuilder()
>    .setNamingStrategy( ... )
>    .buildMetadata();
> 
> Now the naming strategy is associated with this "metadata builder" which is more semantically correct.  But this is a bit verbose for today since I can only think of naming strategy as falling into this bucket.
> 
> 
> On 04/22/2011 03:37 AM, Emmanuel Bernard wrote:
>> 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
>> 
> 
> -- 
> Steve Ebersole <steve at hibernate.org>
> http://hibernate.org