+1
On Thu, Aug 27, 2015 at 5:12 PM Gail Badner wrote:
> Just a gentle reminder that, in keeping with our project's guidelines[1],
> the 4.2 and 4.3 branches will no longer be actively maintained now that 5.0
> has gone Final.
>
> I plan to do 1 more 4.3 release (4.3.12) [2]. That will be last 4
Just a gentle reminder that, in keeping with our project's guidelines[1],
the 4.2 and 4.3 branches will no longer be actively maintained now that 5.0
has gone Final.
I plan to do 1 more 4.3 release (4.3.12) [2]. That will be last 4.3
release.
Applications using Hibernate ORM 4.3 should be migrat
This mailing list is for hibernate developers to discuss Hibernate
development. Please use the user forum for help:
https://forum.hibernate.org/.
On Wed, Aug 26, 2015 at 9:38 PM, Wolfgang Wedemeyer
wrote:
> Greetings Hibernate Developers!
>
> I'm working on an Integrator for Hibernate (backgro
Nevermind. I will not do that. I think I have found a still-easyish way
to do it.
On Thu, Aug 27, 2015 at 10:57 AM Steve Ebersole wrote:
> I do want to pull ORM in to the hibernate-sqm module as a test dependency
> to be able to more easily set up the ModelMetadata stuff based on a
> SessionF
I do want to pull ORM in to the hibernate-sqm module as a test dependency
to be able to more easily set up the ModelMetadata stuff based on a
SessionFactory. That is possibly awkward later when we then use
hibernate-sqm in ORM in terms of having 2 different versions of ORM. I am
open to alternati
2015-08-26 14:41 GMT+02:00 Steve Ebersole :
> On Wed, Aug 26, 2015 at 2:10 AM Gunnar Morling wrote:
>>
>> Hi Steve,
>>
>> > The other approach is to use a 3-phase translation (input
>> > -> semantic-tree -> semantic-SQL-tree(s) -> SQL). This gives a hint to
>> > one
>> > of the major problems. O
> Agreed on the name being sub-par for that usage pattern most of us
> apparently have in mind. So yes, if there was another uniformly-to-use
> method for equality I wouldn't mind limiting the current one to string
> fields.
Cool
--Hardy
___
hibernate-
On Thu, Aug 27, 2015 at 11:34:19AM +0100, Sanne Grinovero wrote:
> Regarding "strong reason", my doubt is just that the method seems
> wrong for the purpose: keyWORD(), and it seems to imply we override an
> explicit user choice.
Right. I also think some sort of understanding is necessary. Obvious
On Thu, Aug 27, 2015 at 10:53:29AM +0100, Sanne Grinovero wrote:
> So.. questions:
>
> 1# Deprecate?
> I'll have to fix the inconsistency for now and make it produce a
> working query in all cases... but do we want to deprecate this and
> have it produce a WARN to state that you really shouldn't u
> > I would say that this throws an exception. At least atm. Numeric encoded
> > fields needs to be targeted by a range query. One could imagine to
> > transparently
> > create a range query in this case. I guess by the metadata we could tell
> > that we have
> > a numeric field. However, that's
i like the idea of "matches" operator for dealing with "is null".
+1
On 26 August 2015 at 19:32, Steve Ebersole wrote:
> https://hibernate.atlassian.net/browse/SQM-11
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jb
2015-08-27 12:34 GMT+02:00 Sanne Grinovero :
> On 27 August 2015 at 11:07, Gunnar Morling wrote:
>> Is there any strong reason for not supporting this on numeric fields?
>> Assuming the remaining corner cases can be fixed (null handling
>> mainly?), my vote goes for keeping the current behaviour.
On 27 August 2015 at 11:07, Gunnar Morling wrote:
> Is there any strong reason for not supporting this on numeric fields?
> Assuming the remaining corner cases can be fixed (null handling
> mainly?), my vote goes for keeping the current behaviour.
Right we can't just change behaviour currently, e
Is there any strong reason for not supporting this on numeric fields?
Assuming the remaining corner cases can be fixed (null handling
mainly?), my vote goes for keeping the current behaviour.
I suppose many people don't think in the technical terms of
"TermQuery" or "NumericRangeQuery" but just in
For the record, Gustavo replied forgetting to CC the list stating that
he would expect it to produce a valid NumericRangeQuery, and that
seems to be the expectation of Adrian too, gauging at some code he
wrote.
That surprised me. I'm personally feeling more comfortable with
Hardy's answer, as I'm
2015-08-27 11:27 GMT+02:00 Hardy Ferentschik :
> On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
>> Assuming you build a Lucene Query the following way:
>>
>> queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>>
>> What is your expectation, if the "age" field
On Wed, Aug 26, 2015 at 09:58:39PM +0100, Sanne Grinovero wrote:
> Assuming you build a Lucene Query the following way:
>
> queryBuilder.keyword().onField( "age" ).matching( 5 ).createQuery();
>
> What is your expectation, if the "age" field is being indexed as a
> NumericField?
I would say
+1
On Thu, Aug 27, 2015 at 10:09 AM, Sanne Grinovero
wrote:
> On 26 August 2015 at 23:20, Steve Ebersole wrote:
> > I'm ok with that. Everyone else?
> >
> >
> > On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling
> wrote:
> >>
> >> hibernate-query-parser?
>
> +1
>
> >>
> >> 2015-08-26 22:32 GMT+02
On 26 August 2015 at 23:20, Steve Ebersole wrote:
> I'm ok with that. Everyone else?
>
>
> On Wed, Aug 26, 2015 at 4:24 PM Gunnar Morling wrote:
>>
>> hibernate-query-parser?
+1
>>
>> 2015-08-26 22:32 GMT+02:00 Steve Ebersole :
>> > I think I'd like to rename this repo and the 2 modules. I th
19 matches
Mail list logo
