>
> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.
I don't understand this part because, for instance, we already support Java
1.8 Date/Time types for quite some time. So, Hibernate 5.x already supports
JPA 2.1 +.
The 5.1 Stream support is also in t
Because Hibernate's Session extends the JPA EntityManager, any methods Vlad
adds to Session effectively "override" the ones from EntityManager - but
allows our internals to use "the forward looking" methods regardless of
whether the underlying JPA libs are 2.1 or 2.2.
On Wed, Aug 2, 2017 at 1:38 P
On 2 August 2017 at 18:40, Gunnar Morling wrote:
> Sure, but you may not publish something like an JPA 2.1+ with just some of
> the 2.2 methods.
Sure, I never proposed that. Just *asked* some clarifications ;)
>
> 2017-08-02 17:40 GMT+01:00 Sanne Grinovero :
>>
>> On 2 August 2017 at 17:07, Gunn
Sure, but you may not publish something like an JPA 2.1+ with just some of
the 2.2 methods.
2017-08-02 17:40 GMT+01:00 Sanne Grinovero :
> On 2 August 2017 at 17:07, Gunnar Morling wrote:
> >> You don't plan on actually updating the JPA API we use at build time
> >> right?
> >
> > We cannot do t
On Wed, Aug 2, 2017 at 7:17 PM, Emmanuel Bernard
wrote:
> You would need to hardcode the definition of Object in HV's code. It's
> unclear to me that it would not be detrimental. I'd keep the model generic.
> And favor metadata recomputation over caching.
I went the "only cache the Object metad
You would need to hardcode the definition of Object in HV's code. It's unclear
to me that it would not be detrimental. I'd keep the model generic. And favor
metadata recomputation over caching.
> On 2 Aug 2017, at 12:49, Sanne Grinovero wrote:
>
> Just nitpicking, as I guess skipping a single
On 2 August 2017 at 17:07, Gunnar Morling wrote:
>> You don't plan on actually updating the JPA API we use at build time
>> right?
>
> We cannot do that, you may not provide a version of a spec'ed API with
> additional methods. It'd have to be in ORM's sub-interface or similar.
The new spec'ed AP
> You don't plan on actually updating the JPA API we use at build time
right?
We cannot do that, you may not provide a version of a spec'ed API with
additional methods. It'd have to be in ORM's sub-interface or similar.
2017-08-02 16:16 GMT+01:00 Sanne Grinovero :
> On 2 August 2017 at 15:21, Vl
I don't think it will break anything since the method will be a default one
in org.hibernate.query.Query
default Stream getResultStream() {
return stream();
}
That will do it.
Vlad
On Wed, Aug 2, 2017 at 6:16 PM, Sanne Grinovero wrote:
> On 2 August 2017 at 15:21, Vlad Mihalcea wrote:
>
On 2 August 2017 at 15:21, Vlad Mihalcea wrote:
> Hi,
>
> I plan on adding the JPA 2.2 Query#getResultStream() method since we
> already support streaming and,
> this way, Hibernate 5.2 will work even if the client has a JPA 2.2
> dependency in their classpath.
>
> https://jcp.org/aboutJava/commun
I thought we had agreed in the E.G. to name this method `#stream` rather
than `#getResultStream`. I've asked for clarification
On Wed, Aug 2, 2017 at 10:02 AM Vlad Mihalcea
wrote:
> Hi,
>
> I plan on adding the JPA 2.2 Query#getResultStream() method since we
> already support streaming and,
> t
Hi,
I plan on adding the JPA 2.2 Query#getResultStream() method since we
already support streaming and,
this way, Hibernate 5.2 will work even if the client has a JPA 2.2
dependency in their classpath.
https://jcp.org/aboutJava/communityprocess/maintenance/jsr338/ChangeLog-JPA-2.2-MR.txt
While w
On 2 August 2017 at 13:28, Guillaume Smet wrote:
> On Wed, Aug 2, 2017 at 1:21 PM, Sanne Grinovero wrote:
>>
>> This might work for HV but please don't do this generally?
>> Concurrently running builds will fail because of conflicting resource
>> usage,
>> and we had plenty of cases in which some
On Wed, Aug 2, 2017 at 1:21 PM, Sanne Grinovero wrote:
> This might work for HV but please don't do this generally?
> Concurrently running builds will fail because of conflicting resource
> usage,
> and we had plenty of cases in which some ports are needd which you
> didn't even know about.
>
At
On 2 August 2017 at 12:13, Guillaume Smet wrote:
> The website jobs are not the only ones that need to be prioritized: the
> release jobs should also be prioritized.
Good point.
>
> When you do a release, it's really a pain to wait for all the other jobs to
> finish.
>
> Currently, I set a weigh
The website jobs are not the only ones that need to be prioritized: the
release jobs should also be prioritized.
When you do a release, it's really a pain to wait for all the other jobs to
finish.
Currently, I set a weight of 2 for the BV/HV release jobs so that they can
also be prioritized.
No
On 23 July 2017 at 21:23, Guillaume Smet wrote:
> On Sat, Jul 22, 2017 at 2:44 PM, Sanne Grinovero
> wrote:
>>
>> I'm not familiar enough with the whole picture but I strongly suspect you
>> should explore ways to get out of this lazy initialization strategy.
>
>
> We have a Jandex POC but it's f
Thank for the IRC logs. To comment on the Jenkins vs 5 Executors "trick":
if it's too limiting +1 to remove this but please always allow a
website release to allow "right now", sometimes it's really urgent and
even waiting a couple of fast jobs is very stressful.
A simple solution - and actually
18 matches
Mail list logo
