[hibernate-dev] org.hibernate.persister.spi.PersisterFactory and 5.0

[Steve Ebersole]

On Thu, Nov 27, 2014 at 3:13 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> 2014-11-27 1:23 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>
>> Part of the goals for ORM 5.0 is moving from Configuration to the
>> ServiceRegistry+Metadata for building a SessionFactory.
>>
>> One of the points I ran into that will have to change
>> is org.hibernate.persister.spi.PersisterFactory.  The problems is that
>> PersisterFactory accepts a Configuration as part of building
>> CollectionPersisters.  The need for Configuration in the standard
>> CollectionPersister impls is amazingly trivial; we literally use it to
>> locate the associated entity's PersistentClass to grab the classes dom4j
>> node name, and this is right after we have just resolved the corresponding
>> EntityPersister.  The point being that the standard CollectionPersisters
>> really don't need access to the Configuration.
>>
>> I am pretty sure OGM provides a custom PersisterFactory, or is it just
>> the PersisterClassResolver that OGM provides?  Also, I would assume OGM is
>> providing custom CollectionPersister impls.  This change would affect both
>> usages.
>>
>
> We don't have a custom PersisterFactory, but there are
> OgmPersisterClassResolver [1] and OgmCollectionPersister [2]. In the latter
> we accept a Configuration in the constructor but just pass it to the super
> 'ctor (AbstractCollectionPersister). We don't do anything ourselves with it.
>

org.hibernate.persister.spi.PersisterClassResolver would not be affected.
But any collection persisters returned from it would be due to their ctors.


>
>> I wanted y'all to be aware of this upcoming change.  But I also wanted to
>> start a discussion about what the signature(s) should become.  Currently
>> we
>> pass:
>>
>> * Configuration
>> * Collection (the parsed mapping info)
>> * CollectionRegionAccessStrategy
>> * SessionFactoryImplementor
>>
>>
>> I suggest we pass:
>>
>> * Collection
>> * CollectionRegionAccessStrategy
>> * SessionFactoryImplementor
>> * Mapping
>>
>
> Should be fine for OGM. I suggest to wrap it into a parameter object
> ("PersisterInitializationContext" or so). That way stuff can be added down
> the road without the need to instantly adapt existing persisters.
>

You know how much I love parameter objects :)  For just this reason...
future-proofing.  I do worry some about the overhead of instantiating all
these though.  Would be good to understand the implications in that
regard.  In fact, if we do this, we may want to do the same for
EntityPersister building.



>
> (I changed order to align with the order for building EntityPersisters)
>>
>> Mapping is org.hibernate.engine.spi.Mapping which is part of
>> Configuration.  I decided to (at least temporarily) port this contract
>> forward to ease migration.  Metadata implements it.
>>
>> There is a similar discussion to be had wrt Integrators.  I will follow up
>> with an email specific to them later.
>>
>
> Regarding the removal of Configuration in general, there will be some more
> work to be done in OGM. We have a custom sub-class, OgmConfiguration [3],
> which is used for two purposes:
>
> 1) Set some properties automatically (to enable OGM's naming strategy and
> query translator etc., use a specific mass indexer for Hibernate Search)
>

These types of things would be done via the various bootstrap hooks.  I say
"various" because there are multiple depending on what exactly you are
trying to achieve, each comes into play at different points in the
bootstrap process.



> 2) Provide an entry point into the API for setting store specific options,
> e.g. like so:
>
>     OgmConfiguration ogmCfg = ...;
>     ogmCfg.configureOptionsFor( MongoDB.class )
>         .entity( GolfPlayer.class )
>             .writeConcern( WriteConcernType.REPLICA_ACKNOWLEDGED );
>

This is akin to the bootstrap "builders" in ORM.  The important point is to
think about where this fits logically in the bootstrap process.  This is
the key differentiation between Configuration and this new bootstrap
approach.