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

Emmanuel Bernard emmanuel at hibernate.org
Thu Nov 27 05:36:42 EST 2014


To add on Gunnar’s needs

3. Use Configuration to extract physical Table structure

We also use configuration in the SchemaDefiner
The SchemaDefiner received the Configuration from a custom implementation of SessionFactoryObserver and use it during sessionFactoryCreated.

The reason we use Configuration is so that this SchemaDefiner contract can:

- access to specific properties (say hibernate.0gm.neo4j.index create-drop )
- get information about the table, it’s unique constraints as shown in this pseudo example

Iterator<Table> tableMappings = configuration.getTableMappings();
while ( tableMappings.hasNext() ) {
   Table table = tableMappings.next();
   if ( table.isPhysicalTable() ) {
      Label label = label( table.getName() );
      PrimaryKey primaryKey = table.getPrimaryKey();
      createConstraint( neo4jDb, table, label, primaryKey );
      @SuppressWarnings("unchecked")
      Iterator<Column> columnIterator = table.getColumnIterator();
      while ( columnIterator.hasNext() ) {
         Column column = columnIterator.next();
         if ( column.isUnique() ) {
            createUniqueConstraintIfMissing( neo4jDb, label, column.getName() );
         }
      }
      Iterator<UniqueKey> uniqueKeyIterator = table.getUniqueKeyIterator();
      while ( uniqueKeyIterator.hasNext() ) {
         createConstraint( neo4jDb, table, label, uniqueKeyIterator.next() );
      }
   }
}


 

> On 27 Nov 2014, at 10:13, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> 2014-11-27 1:23 GMT+01:00 Steve Ebersole <steve at hibernate.org <mailto: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.
> 
> 
>> 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.
> 
> (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)
> 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 );
> 
> We'll need a way to still do 1).
> 
> 2) is not really required. We provide an alternative anyways, for cases
> where you don't bootstrap OGM yourself. You can specify a callback class
> via configuration properties, which then will be invoked and provides the
> entry point to the fluent API.
> 
> --Gunnar
> 
> [1]
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/jpa/impl/OgmPersisterClassResolver.java <https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/jpa/impl/OgmPersisterClassResolver.java>
> [2]
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/persister/impl/OgmCollectionPersister.java <https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/persister/impl/OgmCollectionPersister.java>
> [3]
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/cfg/OgmConfiguration.java <https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/cfg/OgmConfiguration.java>
> 
> 
> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev <https://lists.jboss.org/mailman/listinfo/hibernate-dev>


More information about the hibernate-dev mailing list