[hibernate-dev] OGM options and ORM 5 bootstrap

[Emmanuel Bernard]

I’m torn.
I anticipate that the option programmatic API will be very commonly used, especially when we start bringing new things like custom denormalisation.
It looks quite verbose for a single setting change :/ Is that how all property changes will have to be done in native Hibernate ORM bootstrapping? Or is that not really a user API and people are expected to use JPA’s bootstrap API?
How would the solution look like with an OgmStandardServiceRegistryBuilder?

Emmanuel


> On 02 Jul 2015, at 13:53, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi Emmanuel, all,
> 
> Prior to ORM 5, we used to have OgmConfiguration (sub-class of the dreaded
> Configuration), which provided an entry point into our custom option API:
> 
>    OgmConfiguration config = ...
>    config.configureOptionsFor( MongoDB.class )
>        .associationStorage(IN_ENTITY)
>        ...
>    OgmSessionFactory osf = config.buildSessionFactory();
> 
> Now as of my current in-flight branch of migrating over to ORM 5, the
> equivalent is writing a configurator callback (which also is the only way
> today to do it under JPA):
> 
>    public class MyConfigurator extends OptionConfigurator {
>        public void configure(Configurable configurable) {
>            configurable.configureOptionsFor( MongoDB.class )
>                .associationStorage(IN_ENTITY)
>        }
>    }
> 
> And then plugging it in like so:
> 
>    OgmSessionFactory osf = new MetadataSources(
>        new StandardServiceRegistryBuilder()
>                .applySetting( "hibernate.ogm.option.configurator",
> MyConfigurator.class )
>                .build();
>         )
>        .buildMetadata()
>        .getSessionFactoryBuilder()
>        .unwrap( OgmSessionFactoryBuilder.class )
>        .build();
> 
> Do you consider that good enough? The alternative would be providing our
> own OgmStandardServiceRegistryBuilder or some unwrap on
> StandardServiceRegistryBuilder (it has to be that early, because the
> datastore provider service lives in that service registry, and it may
> consume settings such as the global write concern which is passed to
> MongoDB when connecting). Personally I think what we have is good enough.
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev