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"<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 >
-- 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
