Re: [hibernate-dev] [OGM] Precedence of options specified on different levels
2013/12/3 Emmanuel Bernard <emmanuel(a)hibernate.org>
On Tue 2013-12-03 17:48, Gunnar Morling wrote:
> Thanks, Davide.
>
> 2013/12/3 Davide D'Alto <davide(a)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.
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.