[hibernate-dev] Building a SessionFactory

Emmanuel Bernard emmanuel at hibernate.org
Wed Apr 27 04:29:49 EDT 2011 

I've forked your gist adding comments and my own proposal https://gist.github.com/943902

On 27 avr. 2011, at 00:51, Gail Badner wrote:

> I was getting lost trying to follow this email thread, IRC logs, private conversations, and the confusion due to a typo, so I created a gist page (https://gist.github.com/943347).
> 
> I've tried to summarizes the alternatives and added a couple of my own. I've also included some open questions that need to be resolved.
> 
> I've omitted stuff from when we were confused by the typo.
> 
> Maybe it confuses things even more to put info in yet another place (gist), but I was getting so confused, it's at least helped me to get things straight.
> 
> ----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Emmanuel Bernard" <emmanuel at hibernate.org>
> Cc: hibernate-dev at lists.jboss.org
> Sent: Tuesday, April 26, 2011 11:47:12 AM
> Subject: Re: [hibernate-dev] Building a SessionFactory
> 
> John just pointed out a type here that caused everyone some confusion. 
> I apologize.
> 
> MetadataSources sources = new MetadataSources(...)
>         ...
>         .getMetadataBuilder()
>         .setNamingStrategy( ... )
>         .buildMetadata();
> 
> should really read:
> 
> Metadata metadata = new MetadataSources(...)
>         ...
>         .getMetadataBuilder()
>         .setNamingStrategy( ... )
>         .buildMetadata();
> 
> 
> On 04/26/2011 11:43 AM, Steve Ebersole wrote:
>> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

More information about the hibernate-dev mailing list