2013/12/3 Davide D'Alto <dav...@hibernate.org> > If I understand correctly, What you are suggesting instead, it is to have > two different names for the same property (), defaultHost in the > persistence.xml and host in the API, this means that I have to know how to > call a property based on the place where I want to set it. This is > confusing for me. >
Referring to my last mail, host fails into the category of properties where IMO the XML/properties value should apply. I would name that just "host" in both cases (if even allowing it via the API at all). > > If a a user sets the same property in two different places he will for > sure know that one value will override the other at some point. Why would > he do that otherwise? > > > > > On Tue, Dec 3, 2013 at 4:48 PM, Gunnar Morling <gun...@hibernate.org>wrote: > >> Thanks, Davide. >> >> 2013/12/3 Davide D'Alto <dav...@hibernate.org> >> >>> It looks good to me. >>> >> >> Ok. >> >> > I first didn't like that but I came to think it makes sense, if the >>> property name conveys that semantics, e.g. "defaultAssociationStorageMode". >>> >>> I don't think it's necessary to use the prefix "default". For me it is >>> just a setting that it is overridden by something else in some situations, >>> the same as an annotation is declared at the same time on the class and on >>> an attribute. >>> >> >> From what I can say it's reasonable for a user to expect that properties >> given via persistence.xml or similar actually do apply and are not >> overridden by code or annotations. >> >> Take the MongoDB "host" as example, here we have an internal constant >> with a default but the user can set "hibernate.ogm.mongodb.host" and this >> setting applies. That's different from the proposed algorithm where the >> property really would only be used as fallback if not configuration is >> given by means of annotations or API. >> >> Thus I think it makes sense to make this semantics transparent via the >> "default..." prefix in the property name. >> >> >>> >>> Davide >>> >>> >>> >>> On Tue, Dec 3, 2013 at 9:48 AM, Gunnar Morling <gun...@hibernate.org>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
