[hibernate-dev] Building a SessionFactory

Steve Ebersole steve at hibernate.org
Wed Apr 27 10:01:29 EDT 2011 

I added some comments.  Great thoughts!

On 04/27/2011 03:29 AM, Emmanuel Bernard wrote:
> 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
>

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

More information about the hibernate-dev mailing list