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
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
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo