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" <st...@hibernate.org> > To: "Emmanuel Bernard" <emman...@hibernate.org> > Cc: hibernate-dev@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<st...@hibernate.org> >>>>>> http://hibernate.org >>>>> >>>> >>>> -- >>>> Steve Ebersole<st...@hibernate.org> >>>> http://hibernate.org >>> >> > > -- > Steve Ebersole <st...@hibernate.org> > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
