I wonder if "use streams" is a reasonable replacement for all power
users who might have needed this? We know by experience there's loads
of such people not reading this list, so maybe we'd need a deprecation
cycle.
I don't mean to dive deeply in implementation details and plans, but I
suspect that
It sounds great but I'm not sure it's possible?
For example how would this handle projections? I guess it's a similar
doubt as the one Gunnar shared, but while he suggests a semi-typesafe
solution, I'm not sure how cool it is to give the feeling that types
are being checked when they might actuall
2017-01-02 15:27 GMT+01:00 Steve Ebersole :
> The alternative atm is to directly query against the owning entity or
> directly against the element. Granted that last one assumes that the
> element defines a mapped reference back to the owner to be able to apply
> the restriction based on the FK,
2017-01-03 11:57 GMT+01:00 Sanne Grinovero :
> It sounds great but I'm not sure it's possible?
>
WDYM specifically?
For example how would this handle projections? I guess it's a similar
> doubt as the one Gunnar shared, but while he suggests a semi-typesafe
> solution, I'm not sure how cool it i
On 3 January 2017 at 11:39, Gunnar Morling wrote:
> 2017-01-03 11:57 GMT+01:00 Sanne Grinovero :
>>
>> It sounds great but I'm not sure it's possible?
>
>
> WDYM specifically?
>
>> For example how would this handle projections? I guess it's a similar
>> doubt as the one Gunnar shared, but while he
> If only someone here was a expert of annotation processors maybe he
> could tell me if I'm dreaming :D
:) It's not something you could do with an AP officially as they don't see
the AST below method level.
You could do it by casting to internal implementation types of javac which
will give you
Thanks for the feedback,
header and footer should be fine now.
Thanks,
Davide
On Thu, Dec 29, 2016 at 11:37 PM, Sanne Grinovero wrote:
> Thanks Davide!
> The builds seems to work just fine, the only minor defect I've noticed
> is with the stylesheet doing some strange things when scrolling down
The plan with Stream support here is exactly that... translate the map,
filter etc calls into a SQL query.
On Tue, Jan 3, 2017 at 4:41 AM Sanne Grinovero wrote:
> I wonder if "use streams" is a reasonable replacement for all power
> users who might have needed this? We know by experience there'
On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling wrote:
> 2017-01-02 15:27 GMT+01:00 Steve Ebersole :
> I realize now that Session#createFilter() is only geared towards
> collections. So are you suggesting to only remove that method, but keep
> @Filter/@FilterDef?
>
Correct. @Filter and @FilterD
Inline...
On Tue, Jan 3, 2017 at 4:58 AM Sanne Grinovero wrote:
> It sounds great but I'm not sure it's possible?
>
No idea what this means. Its more than possible. In fact its already
largely done. What do you mean?
For example how would this handle projections?
Exactly the same way you
Inline...
On Tue, Jan 3, 2017 at 5:39 AM Gunnar Morling wrote:
> 2017-01-03 11:57 GMT+01:00 Sanne Grinovero :
>
> Btw. we'd one Tuple type per number of returns, i.e. Tuple2, Tuple3 etc.,
> each with the right number of type arguments. As said I'm not fully
> convinced myself, but some may fin
+1 for removing createFilter()
On 3 January 2017 at 15:54, Gunnar Morling wrote:
> 2017-01-03 15:28 GMT+01:00 Steve Ebersole :
>
> > On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling
> > wrote:
> >
> >> 2017-01-02 15:27 GMT+01:00 Steve Ebersole :
> >> I realize now that Session#createFilter() is on
On 3 January 2017 at 14:26, Steve Ebersole wrote:
> The plan with Stream support here is exactly that... translate the map,
> filter etc calls into a SQL query.
Ah, that sounds awesome!
>
>
> On Tue, Jan 3, 2017 at 4:41 AM Sanne Grinovero wrote:
>>
>> I wonder if "use streams" is a reasonable r
2017-01-03 15:28 GMT+01:00 Steve Ebersole :
> On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling
> wrote:
>
>> 2017-01-02 15:27 GMT+01:00 Steve Ebersole :
>> I realize now that Session#createFilter() is only geared towards
>> collections. So are you suggesting to only remove that method, but keep
>> @
Hi,
Here are the minutes of our biweekly IRC meeting:
16:17 < jbott> Meeting ended Tue Jan 3 15:16:17 2017 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:17 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2
Thanks! Looking forward to using pipelines :)
It seems PR jobs for Hibernate Search do not trigger anymore, though:
* https://github.com/hibernate/hibernate-search/pull/1273 was submitted
yesterday
* there is no build on http://ci.hibernate.org/view/Pull%20Requests/job/
hibernate-search-PR/ sin
Steve -
I'm inclined to agree that changing signatures makes the most sense at
this point.
Chris
On 12/27/2016 04:02 PM, Steve Ebersole wrote:
> FWIW my inclination is to just change the existing signatures. 6.0 is a
> major release with major changes already wrt querying.
>
>
> On Tue, Dec 2
+1
On 01/03/2017 10:02 AM, andrea boriero wrote:
> +1 for removing createFilter()
>
> On 3 January 2017 at 15:54, Gunnar Morling wrote:
>
>> 2017-01-03 15:28 GMT+01:00 Steve Ebersole :
>>
>>> On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling
>>> wrote:
>>>
2017-01-02 15:27 GMT+01:00 Steve Eber
On Tue, Jan 3, 2017 at 6:23 PM, Yoann Rodiere wrote:
> It's a bit odd, because the OGM PR job seems to work fine... From what I
> can see there hasn't been any particular change on the OGM job.
>
As for OGM, the build is triggered but does not report back to GitHub. I
pinged Davide about it a fe
19 matches
Mail list logo
