[hibernate-dev] [OGM] Precedence of options specified on different levels

[Gunnar Morling]

2013/12/3 Emmanuel Bernard <emmanuel at hibernate.org>

> I am quite uncomfortable with that approach.
>
> Here is what I propose instead (we did discuss that in the past a bit).
>
> Rules by decreasing precedence:
>
> property | association > class > super class > global
> (*) question: what about overridden properties
>
> For a given level mentioned above,
> API > annotation > file/property based configuration
>

Ok, let's get started that way then. As discussed on IRC I'd find it useful
if there was the option to ignore annotations on a given level or globally,
so one can use the API to e.g. efficiently re-configure a model which
sources one can't change. But that can be done in a second step.

Regarding overridden properties, I think I'd give property config
precedence over class config on each level of the hierarchy.

This leaves open the corner case of options on properties declared in two
parallel interfaces. I'd mandate options to be given on classes rather than
interfaces to avoid this issue and get started.


> This is how JPA does it (API overrides annotations per level), same for
> Hibernate Search and I suspect Hibernate Validator. I never had anything
> bad to say about this approach in my past experience.
>
> Emmanuel
>
> On Tue 2013-12-03 10:48, Gunnar Morling wrote:
> > Hi,
> >
> > In the context of embedded associations for CouchDB [1], I'm working on
> > support for configuring the association storage mode using our new option
> > system [2]. I can see the following "axes" of configuration here:
> >
> > * via annotation
> >   - on an association property
> >   - on a type
> > * via the option API
> >   - on an association property
> >   - on a type
> >   - on the global level
> > * via a configuration property as given via OgmConfiguration,
> > persistence.xml etc.
> > * on super-types
> >   - via annotations or API
> >   - on the property or entity level
> >
> > I'm looking now for a sensible and comprehensible algorithm for taking
> > these sources of configuration into account and determining the effective
> > setting for a given association. This could be one way:
> >
> > 1) check API
> >   a) look for a setting given via the programmatic API for the given
> > property
> >   b) if the property is not configured, look for a setting given for the
> > entity
> >   c) if the entity itself is not configured, repeat a) and b) iteratively
> > on super-types if present
> >   d) if no type from the hierarchy is configured look for the global
> setting
> >
> > 2) check annotations
> >   if no configuration could be found in 1), do the same for annotations,
> > i.e.
> >   a) look for configuration on the given property
> >   b) look for configuration on the given entity
> >   c) repeat a) and b) iteratively on super-types if present
> >
> > 3) take default value given via OgmConfiguration/persistence.xml etc.
> >
> > This algorithm ensures that:
> > * API configuration always takes precedence over annotation
> configuration;
> > e.g. if a super-type is configured via the API or the setting is given on
> > the API global level, any annotations are ignored
> > * "More local" configuration takes precedence; i.e. a type's own
> > configuration wins over configuration from super-types, property-level
> > configuration wins over entity-level configuration
> >
> > Note that any setting given via OgmConfiguration/persistence.xml would be
> > handled as last fallback option, i.e. any configuration given via
> > annotations or the API would take precedence over that. I first didn't
> like
> > that but I came to think it makes sense, if the property name conveys
> that
> > semantics, e.g. "defaultAssociationStorageMode".
> >
> > Any other thoughts or alternative approaches around this?
> >
> > Thanks,
> >
> > --Gunnar
> >
> > [1] https://hibernate.atlassian.net/browse/OGM-389
> > [1] https://hibernate.atlassian.net/browse/OGM-208
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>