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

[Guillaume SCHEIBEL]

Hi guys,

That sounds nice. Are association storage strategies already using this new
feature ?


Guillaume


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).
>
> 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?
>
> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>