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.

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 <gunnar(a)hibernate.org&gt;wrote: > Thanks, Davide. > > 2013/12/3 Davide D'Alto <davide(a)hibernate.org&gt; > >> 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 <gunnar(a)hibernate.org&gt;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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> >

On Tue 2013-12-03 17:48, Gunnar Morling wrote: > Thanks, Davide. > > 2013/12/3 Davide D'Alto <davide(a)hibernate.org&gt; > > > 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. Realize guys that we have a sparse matrix model. Not all settings will be applicable globally AND per entity AND per property. host for example, probably should not have a entity/property level.

We might want to allow for it to be set programmatically globally but in that case, I'd argue that the program should have priority over the XML.

On Wed 2013-12-04 10:33, Gunnar Morling wrote: > 2013/12/3 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > > > On Tue 2013-12-03 17:48, Gunnar Morling wrote: > > > Thanks, Davide. > > > > > > 2013/12/3 Davide D'Alto <davide(a)hibernate.org&gt; > > > > > > > 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. > > > > Realize guys that we have a sparse matrix model. Not all settings will > > be applicable globally AND per entity AND per property. > > host for example, probably should not have a entity/property level. > > > Yes, sure. > > > > We > > might want to allow for it to be set programmatically globally but in > > that case, I'd argue that the program should have priority over the XML. > > > > Why would you argue that way? > > IMO one needs to distinguish two different categories of properties here. > API > XML makes sense for properties where the XML property defines a > default in case no value is given via other means; hence the suggested > "default..." prefix. Association storage is an example; there are no > associations to be stored on the global level per-se, instead giving the > value via XML or globally acts as fallback in case no value is specified > for a given association. > > But there is another category of properties where the value from XML, > hibernate.properties etc. ultimately should be applied. The host falls into > this category. Often such setting is configured by someone executing > deployments, e.g. by providing a properties file within the environment, > rather than by a developer. So one can take one and the same artifact, > deploy it in different environments and have it work with different > database hosts. > > I'd even argue that setting the host via the API is not really useful for > that reason. But if it is possible to set this value via the API, the > XML/properties value should take precedence IMO. I do disagree. First off, I am not certain host should be an option. It could just remain a property.

But assuming we want an API way to define host, I think it should have priority over properties. That way, I can write a piece of code that takes the host value from somewhere and apply it. This piece of code can even read that value from persistence.xml if it wants to. Why would you have a programmatically defined host just to have it be erased by the static xml/properties file?

Emmanuel