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
