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