[hibernate-dev] Building a SessionFactory

[Steve Ebersole]

Builder is a generic term.  The specific function served here is that of 
a set of sources for metadata.

The same does not hold for ServiceRegistryBuilder.  It does not hold a 
singular type of information.  In fact initially I shied away from the 
name ServiceRegistryBuilder because of its genericness.  But in the end 
decided to use it because it would be familiar to developers.

On 04/26/2011 11:05 AM, Emmanuel Bernard wrote:
> 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
>

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org