[hibernate-dev] Building a SessionFactory

Gail Badner gbadner at redhat.com
Tue Apr 26 18:51:57 EDT 2011 

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