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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
