6:53 a.m.
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
9:47 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:27 a.m.
2015-07-02 16:47 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
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?
AFAICS, it'd be the way for bootstrapping native Hibernate. Note that for
most settings there are proper typed setters on MetadataBuilder. Things
like dialect, user name etc. can be configured through props in the usual
files, the same could be done for our OGM configurator class name.
How would the solution look like with an
OgmStandardServiceRegistryBuilder?
The problem is that the option API allows to set things possibly needed by
the datastore provider. Which is a service in the standard service
registry, so we cannot apply these configurations only at the
(Ogm)SessionFactoryBuilder level, that'd be too late.
The following would be possible:
OgmStandardServiceRegistryBuilder ossrb = new
OgmStandardServiceRegistryBuilder();
ossrb.configureOptionsFor( MongoDB.class )
.associationStorage(IN_ENTITY);
OgmSessionFactory osf = new MetadataSources( ossrb.build() )
.buildMetadata()
.getSessionFactoryBuilder()
.unwrap( OgmSessionFactoryBuilder.class )
.build();
I wouldn't like it too much though because it seems very odd to have these
mapping options exposed at that level.
One alternative would be to make DatastoreProvider a service of the
SessionFactory service registry; Then these options could be configured at
a later point (e.g. an OGM-specific MetadataBuilder impl as discussed in
the other mail, or on our SessionFactoryBuilder) which seems nicer. It'd
require though that the operations of GridDialect (which is a standard
service itself, and I think it needs to stay that way as it is exposed
through OgmDialect to id generators) receive DatastoreProvider as parameter.
Or we don't support configurator options targeting DatastoreProvider (which
may be fine, e.g. write concern/read pref in MongoDB can be passed to all
driver ops, so there is no strong need to pass them upon connection
creation).
Personally I think specifying the configurator FQN as prop e.g. in
hibernate.cfg.xml is acceptable (similar to what you did for JPA).
Emmanuel
> On 02 Jul 2015, at 13:53, Gunnar Morling <gunnar(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3434
days inactive
3435
days old
2 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Gunnar Morling