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

[Gunnar Morling]

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

> So currently in the pull request, we now have the following
>
> 1. property > entity > global
> 2. for each level in 1., programmatic API beats annotation
>
> These are simple rules to understand and all it good.
>
> Now Gunnar tried to handle class inheritance, ie superclasses and
> overridden methods.
> And we do differ in what we consider the natural rules (or what it
> should be).
>
> Here is how I think the rules should be:
>
> 1. property > entity > global
> 2. for each level in 1., subclass > superclass and overridden method >
> parent method
> 3. for each level (in 1 and 2), programmatic API beats annotation
>
> Here is how Gunnar thinks the rules should be:
>
> 1. metadata on a class > metadata on a superclass (whether it is on a
> property or the class)
> 2. for each hierarchy level, property > entity > global
> 3. for each level in 1 and 2, programmatic API beats annotation
>
> In more concrete words,
>
>     @Option(1)
>     class A {
>         @Option(2)
>         public String getMe() {return null;}
>     }
>
>     @Option(3)
>     class B extends A {
>         @Override
>         public String getMe() {return null;}
>     }
>
> In my world, B.getMe has Options(2).
> In Gunnar's world, B.getMe() has @Option(3).
>

Thanks for the clear explanation and example for the issue.


> To me, a property level is always more specific than an entity, hence my
> interpretation. If someone has set a value on a given property, it would
> be dangerous to be "globally" overridden by a subclass.
>
> Thoughts?
>

What would be "dangerous" in this case?

I think for the author of B it's helpful to be able to change the defaults
for the entire class. Also for a reader of B its simpler to grasp the
applying configuration with my proposal, because the entire "truth" about
the annotation config can be found in B, you don't have to look into any
super-classes. So to me, that's more along the lines of the principle of
least surprise.

That said I'm not sure whether really one option is more "natural" than the
other, seems like it can be defined either that way or the other.

Davide, Sanne, Guillaume, others, what's your take on this?


>
> 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
>