[hibernate-dev] [OGM] Precedence of options specified on different levels
Emmanuel Bernard
emmanuel at hibernate.org
Tue Dec 3 12:32:48 EST 2013
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
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
More information about the hibernate-dev
mailing list