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