[hibernate-dev] API/SPI in 5.0

[Emmanuel Bernard]

For OGM the impact is less but in
Integrator.integrate
we use Configuration to be able to conditionally add a naming strategy configuration.setNamingStrategy().

Not sure what to do here either in the 
ntegrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)
case.

We don’t use PersisterFactory but rather override the PersisterClassResolver service.

Emmanuel

On 06 Feb 2014, at 13:46, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> I have looked at Search and identified the elements that use
> Configuration and it's access to mapping.
> 
> During bootstrap via an Integrator, we use
> 
> Configuration.getProperties()
> Configuration.getreflectionManager (optional)
> cfg.getClassMappings()
> 
> The properties are used to bootstrap Hibernate Search as we receive our
> properties form the Hibernate ORM configurations
> 
> The class mappings is necessary for us as it offers the list of entities
> we need to look at. From them, we bootstrap with the subsection that are
> @Indexed entities.
> We do that by associating a SF Observer and passing in the Configuration
> object and using the SF instance passed.
> This observer is initialized by the Integrator.
> 
>> From what I understand the replacement for
> Integrator.integrate(Configuration, SessionFactoryImplementor, SessionFactoryServiceRegistry)
> is
> Integrator.integrate(MetadataImplementor, SessionFactoryImplementor, SessionFactoryServiceRegistry)
> 
> How we get access to the properties and the list of mapped classes in
> the new form?
> 
> Emmanuel
> 
> On Fri 2014-01-31 14:14, Steve Ebersole wrote:
>> As we transition to 5.0 we have to make a lot of decisions wrt API/SPI 
>> methods that are no longer relevant.  I think it is better to look at 
>> these individually.
>> 
>> == Configuration
>> 
>> I went ahead and made a preliminary decision here as I discussed in 
>> HHH-7164.  The thinking is that we had some leeway here because 
>> Configuration had been deprecated (and pretty widely known to be 
>> deprecated based on StackOverflow and other sources).   Basically I made 
>> Configuration a simple delegate to the new Metadata building code.  I 
>> removed all the methods that exposed access to the org.hibernate.mapping 
>> objects that Configuration used to manage.
>> 
>> ---
>> 
>> == Integrator
>> 
>> This one is a little tougher.  In retrospect I think I would have just 
>> gone for a number of discrete contributor contracts.  For example, 
>> usually Integrator is used to add event listeners, so an 
>> EventListenerContributor would have worked.  Then I would have used 
>> Integrator as a grouping of contributors.
>> 
>> 
>> == PersisterFactory (and persister constructors)
>> 
>> Forms taking Configuration and org.hibernate.mapping objects should, 
>> imo, get removed.  But I can live with deprecation if someone wants to 
>> "pound the table" for that.  But realize that the 
>> Configuration+org.hibernate.mapping forms would not be called ever.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev