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.

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

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.

_______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt; wrote: Hi, 2014-11-27 1:23 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: 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... [2] https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java... [3] https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Actually, I take that back about Metadata extending org.hibernate.cfg.Mappings. I had contemplated doing that, but decided against it since Mappings exposes all kinds of "extra" stuff that isn't actually mappings/metadata (config info, contextual info, etc) and I did not want to fuglify these new contracts that way. On Thu, Nov 27, 2014 at 10:25 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Well naturally there is still access to all this information :) > > IMO SessionFactoryObserver is a hack way of doing this. With 5.0, the > way to do this would be one of the various bootstrap hooks I mentioned > earlier. Specifically you want a hook that is called just after all > metadata is fully known. > > BTW, for 5.0 the "metadata" is still using the mappings as defined in the > org.hibernate.mapping package. So all that code fragment will continue to > work aside from actually using the Configuration. Interestingly, had > you used org.hibernate.cfg.Mappings#iterateTables rather than Configuration#getTableMappings(), > this code would have continued to work with no changes at all. This is the > point I made in the initial email about Metadata also being a > org.hibernate.cfg.Mappings. > > > On Thu, Nov 27, 2014 at 4:36 AM, Emmanuel Bernard <emmanuel(a)hibernate.org > > wrote: > >> 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(a)hibernate.org&gt; wrote: >> >> Hi, >> >> 2014-11-27 1:23 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >> 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... >> [2] >> >> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java... >> [3] >> >> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java... >> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >

Wanted to point out that I carried those signatures on to the persister ctors as well.

just after all persisters have been built. Exactly what information did that hook need access to?

> As for the "parameter object", I came up with a decent (imo) solution. > So I only wrap the things that are "contextual". Here is the contract > right now: > > > public interface PersisterFactory extends Service { > /** > * "Parameter object" providing access to additional information that may > be needed > * in the creation of the persisters. > */ > public static interface PersisterCreationContext { > SessionFactoryImplementor getSessionFactory(); > Metadata getMetadata(); > } > > /** > * Create an entity persister instance. > * > * @param entityBinding The mapping information describing the entity > * @param entityCacheAccessStrategy The cache access strategy for the > entity region > * @param naturalIdCacheAccessStrategy The cache access strategy for the > entity's natural-id cross-ref region > * @param creationContext Access to additional information needed to > create an EntityPersister > * > * @return An appropriate entity persister instance. > * > * @throws HibernateException Indicates a problem building the persister. > */ > public EntityPersister createEntityPersister( > PersistentClass entityBinding, > EntityRegionAccessStrategy entityCacheAccessStrategy, > NaturalIdRegionAccessStrategy naturalIdCacheAccessStrategy, > PersisterCreationContext creationContext) throws HibernateException; > > /** > * Create a collection persister instance. > * > * @param collectionBinding The mapping information describing the > collection > * @param cacheAccessStrategy The cache access strategy for the > collection region > * @param creationContext Access to additional information needed to > create an EntityPersister > * > * @return An appropriate collection persister instance. > * > * @throws HibernateException Indicates a problem building the persister. > */ > public CollectionPersister createCollectionPersister( > Collection collectionBinding, > CollectionRegionAccessStrategy cacheAccessStrategy, > PersisterCreationContext creationContext) throws HibernateException; > > } > > PersisterCreationContext is the contextual info. And it can be > "statically" defined for each and every call into PersisterFactory. The > other params to #createEntityPersister and #createCollectionPersister are > specific to that call. > > > On Thu, Nov 27, 2014 at 10:35 AM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Actually, I take that back about Metadata extending org.hibernate.cfg.Mappings. >> I had contemplated doing that, but decided against it since Mappings >> exposes all kinds of "extra" stuff that isn't actually mappings/metadata >> (config info, contextual info, etc) and I did not want to fuglify these new >> contracts that way. >> >> On Thu, Nov 27, 2014 at 10:25 AM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> Well naturally there is still access to all this information :) >>> >>> IMO SessionFactoryObserver is a hack way of doing this. With 5.0, the >>> way to do this would be one of the various bootstrap hooks I mentioned >>> earlier. Specifically you want a hook that is called just after all >>> metadata is fully known. >>> >>> BTW, for 5.0 the "metadata" is still using the mappings as defined in >>> the org.hibernate.mapping package. So all that code fragment will continue >>> to work aside from actually using the Configuration. Interestingly, >>> had you used org.hibernate.cfg.Mappings#iterateTables rather than >>> Configuration#getTableMappings(), this code would have continued to >>> work with no changes at all. This is the point I made in the initial email >>> about Metadata also being a org.hibernate.cfg.Mappings. >>> >>> >>> On Thu, Nov 27, 2014 at 4:36 AM, Emmanuel Bernard < >>> emmanuel(a)hibernate.org&gt; wrote: >>> >>>> 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(a)hibernate.org&gt; wrote: >>>> >>>> Hi, >>>> >>>> 2014-11-27 1:23 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>> 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... >>>> [2] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java... >>>> [3] >>>> >>>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java... >>>> >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >>>> >>> >> >

Hi, 2014-11-27 1:23 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > 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 );