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

2013-12-03 Thread Gunnar Morling
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 AP

Re: [hibernate-dev] Annotation Processors

2013-12-03 Thread Hardy Ferentschik
On 2 Jan 2013, at 18:12, Steve Ebersole wrote: > Well technically it is not valid according to the javac spec, which was > David's point (which I assume who you are referring to). What is against the spec? To run 'javac -proc:only’? > And in fact we get a slew of errors from running `javac -

Re: [hibernate-dev] Annotation Processors

2013-12-03 Thread Steve Ebersole
On Tue 03 Dec 2013 04:39:43 AM CST, Hardy Ferentschik wrote: > > On 2 Jan 2013, at 18:12, Steve Ebersole wrote: > >> Well technically it is not valid according to the javac spec, which was >> David's point (which I assume who you are referring to). > > What is against the spec? To run 'javac -pr

Re: [hibernate-dev] Annotation Processors

2013-12-03 Thread Hardy Ferentschik
On 3 Jan 2013, at 13:29, Steve Ebersole wrote: >>> And in fact we get a slew of errors from running `javac -proc:only`. We >>> just happen to eat/ignore them. >> >> Sure, in some cases you might have to run the processors as part of the main >> compile. Still, imo nothing wrong with the way

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

2013-12-03 Thread Gunnar Morling
Thanks, Davide. 2013/12/3 Davide D'Alto > 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 >

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

2013-12-03 Thread Davide D'Alto
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.

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

2013-12-03 Thread Emmanuel Bernard
I am quite uncomfortable with that approach. Here is what I propose instead (we did discuss that in the past a bit). Rules by decreasing precedence: property | association > class > super class > global (*) question: what about overridden properties For a given level mentioned above, API > ann

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

2013-12-03 Thread Emmanuel Bernard
On Tue 2013-12-03 17:48, Gunnar Morling wrote: > Thanks, Davide. > > 2013/12/3 Davide D'Alto > > > 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". > > > >

Re: [hibernate-dev] [OGM] Distinguishing embedded collections and associations in document stores

2013-12-03 Thread Emmanuel Bernard
We probably need to revisit what we really want to test and adjust the test accordingly. AFAIR, these tests felt weak anyways. On Fri 2013-11-29 11:49, Gunnar Morling wrote: > Hi, > > I'm working on support for embedded associations in CouchDB [1]. Checking > how this is mapped by the MongoDB dia

Re: [hibernate-dev] [OGM] Distinguishing embedded collections and associations in document stores

2013-12-03 Thread Gunnar Morling
Thanks for following up on this. 2013/12/3 Emmanuel Bernard > We probably need to revisit what we really want to test and adjust the > test accordingly. AFAIR, these tests felt weak anyways. > Yes, that has been on my agenda for some day anyways. Test failures are hard to analyze as the asserti

[hibernate-dev] ORM 4.3 CR2 heads-up

2013-12-03 Thread 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