> 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.
Where do you think we should keep these needs. Maybe as subtasks of a ORM 5 issue, to make
sure we don’t miss them?
Gunnar, you are the (designated) man :)
> 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.
I don’t know when we need to do that but I think it would be useful to see how we could
achieve extensibility or composability of the ORM builders to add Search or OGM specific
building information That’s something that is still very blurry to me at this stage.