master -> metamodel
by Steve Ebersole
When is the last time we have synced merged master to the metamodel branch?
12 years, 1 month
Re: [hibernate-dev] [OGM] Precedence of options specified on different levels
by Gunnar Morling
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.
>
> Davide
>
>
>
> On Tue, Dec 3, 2013 at 9:48 AM, Gunnar Morling <gunnar(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
12 years, 1 month
ORM 4.3 CR2 heads-up
by Steve Ebersole
For various reasons I need to cut a second CR for 4.3. I will do that
release on Thursday the 5th.
Prior to that I need to make sure that both the JPA TCK and the
persistence portions of the EE TCK (within WidlFly) pass; trouble is
that the jobs which run the persistence portions of the EE TCK currently
can take up to 24 hours to complete. Part of the problem is that they
sit in queue for a long time in a very overwhelmed CI environment; part
is that they just take a long time.
So I really need all pushes that need to go into this CR2 to be pushed
to the upstream GitHub repo within the next few hours. That will give
us time to run the TCK jobs and verify the results (and fix any
regressions with time to re-run the TCK jobs, should there be any
regressions). I said I would do the release on the 5th; if the first
TCK runs complete in time and all succeed, I may try to release tomorrow
(the 4th).
So with all that in mind, I am asking that any pushes going into CR2
happen within in 2 hours (before 6pm Eastern US time today, Dec 3rd).
Also, I am asking that no pushes happen to upstream master from this
point on until after CR2 release is done.
Sorry for the restrictions, but understand that this is special set of
releases due to JPA 2.1 testing and certification.
Thanks!
12 years, 1 month
[OGM] Distinguishing embedded collections and associations in document stores
by Gunnar Morling
Hi,
I'm working on support for embedded associations in CouchDB [1]. Checking
how this is mapped by the MongoDB dialect I saw its done like this (here
with an order column):
{
"_id": "123",
"orderedChildren": [
{
"birthorder": 0,
"orderedChildren_id": "456"
},
{
"birthorder": 1,
"orderedChildren_id": "789"
}
]
}
Just looking at this document one can't tell whether "orderedChildren"
actually represents an association or an embedded collection. For our
engine that's no problem as it knows the kind of the element from its
meta-model.
We have a testing approach though which makes assertions on the number of
associations stored in the database. With the representation described
above the number of embedded associations can't be determined on the
server-side alone (using a "view" in CouchDB terms).
Besides from adding an attribute which describes the kind of a collection
(which wouldn't be so nice as it was just for testing purposes), I don't
see any other way than obtaining all the candidates and single out actual
associations on the client based on the meta-model.
Maybe anyone has a better idea?
Btw. for MongoDB the problem is ignored by having the assertion method
always return true in this case.
--Gunnar
[1] https://hibernate.atlassian.net/browse/OGM-389
12 years, 1 month
Annotation Processors
by Steve Ebersole
I started today on removing the separate calls to javac to execute
Annotation Processors in the Hibernate ORM build. From Gradle it is
working fine. However when I try to enable Annotation Processing in
IntelliJ, it complains about the "module cycle" between hibernate-core
and hibernate-testing.
I'd really like to get a gauge on how many people really use
hibernate-testing.
12 years, 1 month
