[hibernate-dev] [OGM] Precedence of options specified on different levels

[Gunnar Morling]

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