[hibernate-dev] Should we deprecate @Similarity

2013-09-19 Thread Sanne Grinovero
Discussing about some hibernate-search-engine complexities with Hardy on IRC, we came to the agreement that the way @Similarity behaves today was a mistake, so we're proposing to deprecate it in 4.4. Reasoning follows. There is a strong requirement in Lucene that all operations on the same index

Re: [hibernate-dev] Should we deprecate @Similarity

2013-09-19 Thread Hardy Ferentschik
On 19 Jan 2013, at 5:15 PM, Sanne Grinovero wrote: > Discussing about some hibernate-search-engine complexities with Hardy > on IRC, we came to the agreement that the way @Similarity behaves > today was a mistake, so we're proposing to deprecate it in 4.4. > > Reasoning follows. > > There is a

[hibernate-dev] handling in JPAOverriddenAnnotationReader

2013-09-19 Thread Steve Ebersole
I had to hook into processing within JPAOverriddenAnnotationReader so I took the opportunity to reorganize the code. As part of that there were 2 pieces of code in particular that I could not figure out the purpose of: 1) We were excepting as a sub-element of . The code even had a comment a

[hibernate-dev] IRC Developer Meeting - Sept 19

2013-09-19 Thread Steve Ebersole
Discussed plans for merging hibernate-core and hibernate-entitymanager mostly (how, when, etc)... [11:14] Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-09-19-15.00.html [11:14] Minutes (text): http://transcripts.jboss.org/meeting/irc.free

Re: [hibernate-dev] Function support in ProcedureCall/StoredProcedureQuery

2013-09-19 Thread Hardy Ferentschik
On 19 Jan 2013, at 3:46 PM, Steve Ebersole wrote: > The trouble is that hints are valid on StoredProcedureQuery whether named or > not. If we go the route of using hints for annotations, doesn't it make > sense to be consistent and use that when building a StoredProcedureQuery too? For me a

Re: [hibernate-dev] Function support in ProcedureCall/StoredProcedureQuery

2013-09-19 Thread Steve Ebersole
The trouble is that hints are valid on StoredProcedureQuery whether named or not. If we go the route of using hints for annotations, doesn't it make sense to be consistent and use that when building a StoredProcedureQuery too? On 09/19/2013 03:54 AM, Hardy Ferentschik wrote: > Here are my 0.02

[hibernate-dev] StoredProcedureQuery parameters

2013-09-19 Thread Steve Ebersole
StoredProcedureQuery spq = ...; spq.registerStoredProcedureParameter( 1, Calendar.class, ParameterMode.IN ); spq.setParameter( 1, aGregorianCalendar, TemporalType.DATE ); We have some failures against the TCK for this scenario. There are 2 ways to solve this, and I wanted to get opinions on the

Re: [hibernate-dev] Function support in ProcedureCall/StoredProcedureQuery

2013-09-19 Thread Hardy Ferentschik
Here are my 0.02$ which need to be taken with a grain of salt since I am not so familiar with the procedure call stuff. On 17 Jan 2013, at 6:15 PM, Steve Ebersole wrote: > In my opinion, ideally the JPA spec would have defined a separate method > to register a "function return". Luckily since

Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

2013-09-19 Thread Gunnar Morling
I also think that the conversion of the ConstraintViolation(s) into another format is more in the responsibility of the integrating technology. Taking JAX-RS/Resteasy as example, it will transparently convert any constraint violation objects into an equivalent XML or JSON response. Provided we ret

Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

2013-09-19 Thread Gunnar Morling
Yes, the use case seems quite specific. I've created https://hibernate.atlassian.net/browse/HV-823 to keep track of this. 2013/9/19 Hardy Ferentschik > Seems to me like a very specific use case. I guess we could offer a > contract as you suggest, but it is not > high on my priority list. Worth

Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

2013-09-19 Thread Hardy Ferentschik
On 19 Jan 2013, at 9:44 AM, Emmanuel Bernard wrote: > It seems that what this user really needs is a way to convert the > Set into another format entirely, JSON in this case. I > wonder if we could find a more generic approach than just the ability to > change properties names. Well, there

Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

2013-09-19 Thread Hardy Ferentschik
Seems to me like a very specific use case. I guess we could offer a contract as you suggest, but it is not high on my priority list. Worth creating a Jira issue for though. --Hardy On 19 Jan 2013, at 9:05 AM, Gunnar Morling wrote: > Hi, > > On SO [1], a user asked whether it's possible to r

Re: [hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

2013-09-19 Thread Emmanuel Bernard
It seems that what this user really needs is a way to convert the Set into another format entirely, JSON in this case. I wonder if we could find a more generic approach than just the ability to change properties names. On 19 sept. 2013, at 09:05, Gunnar Morling wrote: > Hi, > > On SO [1], a

[hibernate-dev] [HV] Extending ParameterNameProvider contract for other element types

2013-09-19 Thread Gunnar Morling
Hi, On SO [1], a user asked whether it's possible to report custom names for property constraint violations, e.g. "nm" as retrieved from the annotation in this case: @JsonProperty("nm") @NotNull final public String name; At the moment that's not possible with HV, but one might think