Re: [hibernate-dev] Building a SessionFactory

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&lt;steve(a)hibernate.org&gt; >>>> http://hibernate.org >>> >> >> -- >> Steve Ebersole&lt;steve(a)hibernate.org&gt; >> http://hibernate.org >