I would suggest a Beta2, as we were hoping to still do some work on
it. No strong take though, as far as I know our pending work is
optional / low impact:
A. produce the feature packs in ORM
B. test OGM integration
Status of these:
A#
The feature packs have low impact on ORM's risk and quality,
having a Beta2 release is fine also to me
On 31 January 2018 at 10:26, Sanne Grinovero wrote:
> I would suggest a Beta2, as we were hoping to still do some work on
> it. No strong take though, as far as I know our pending work is
> optional / low impact:
> A. produce the feature packs in ORM
>
Hi,
Just so you know, I just made a few minor changes to the website:
- in the Releases dymanic submenu, you now have a label stating "latest
stable"/"development" to make it clearer what the versions are (it's
especially useful at this point of the ORM development for instance as 5.3
is the lates
Sounds great, thanks!
On 31 January 2018 at 12:15, Guillaume Smet wrote:
> Hi,
>
> Just so you know, I just made a few minor changes to the website:
> - in the Releases dymanic submenu, you now have a label stating "latest
> stable"/"development" to make it clearer what the versions are (it's
> e
Looks great! Thanks
On Wed, Jan 31, 2018 at 8:18 AM Sanne Grinovero wrote:
> Sounds great, thanks!
>
> On 31 January 2018 at 12:15, Guillaume Smet
> wrote:
> > Hi,
> >
> > Just so you know, I just made a few minor changes to the website:
> > - in the Releases dymanic submenu, you now have a la
I have no strong preference either way.
On 01/30/2018 05:00 PM, Steve Ebersole wrote:
> Wanted to remind everyone that tomorrow is the next time-boxed release for
> 5.3.
>
> I wanted to get everyone's opinions about the version number, whether this
> should be Beta2 or CR1. IMO It depends how you
I would say let's go for Beta2. We are not in a hurry considering the
challenges still pending so no need to rush in the CR phase.
On the NoORM side:
- Search - Yoann has prepared a PR with the 5.3 support so we should be OK
on this side. 5.9 will be tagged early next week and we'll release an alp
Didn't we discuss this at our last meeting?
The general opinion - and final verdict - was that doing like you're
asking now again would be way too much work and not generally worth
it, not least not in the best interest of all our users. Technically
it's certainly possible, but a lot of work going
The next time-box is in fact 2 weeks... :)
Hopefully we have these JPA TCK challenges resolved by then and can do CR
then. So yes, please have feedback by then. Yoann and I have been working
on Search and ORM 5.3 (at least parts) so I think that will work out fine.
But yes, OGM makes me a little
Not to mention, I'm really not even sure what this request "means". As we
all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory and
Session/EntityManager, and that caused us to have to make changes to
certain method signatures - most notably `Session#getFlushMode` was one of
the pr
On Wed, Jan 31, 2018 at 4:42 PM, Steve Ebersole wrote:
> The next time-box is in fact 2 weeks... :)
>
> But yes, OGM makes me a little nervous as as far as I know we have no idea
> about that integration yet
>
We discussed it on Tuesday at our meeting.
I think we can commit to getting your feed
Yes, I agree. As it is, it is very likely that in 2 weeks we will have ORM
5.3.0.CR1. So even if you did do a OGM release at that time we are going
to be limited in what exactly we can change if we find changes are needed.
Interestingly this goes back to earlier discussions about "release
early/
On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole wrote:
> Yes, I agree. As it is, it is very likely that in 2 weeks we will have
> ORM 5.3.0.CR1. So even if you did do a OGM release at that time we are
> going to be limited in what exactly we can change if we find changes are
> needed.
>
> Inter
HHH-12257 involves refreshing an entity that is already has a pessimistic
lock. In the test case attached to the jira, EntityManager#refresh(Object
entity) is used to refresh the entity, instead of a method that specifies a
particular LockModetype (e.g., #refresh(Object entity, LockModeType
lockMod
Hi Gail,
personally I wouldn't expect the pessimistic lock to be dropped.
In case of optimistic locking, I would expect the version to be
updated to the latest read - the one triggered by the refresh.
I just read section 3.4 as you suggested but I couldn't find were it
suggests that "a lock on a
See below...
On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero
wrote:
> Hi Gail,
>
> personally I wouldn't expect the pessimistic lock to be dropped.
> In case of optimistic locking, I would expect the version to be
> updated to the latest read - the one triggered by the refresh.
>
Yes, the ver
On 31 January 2018 at 21:48, Gail Badner wrote:
> See below...
>
> On Wed, Jan 31, 2018 at 1:20 PM, Sanne Grinovero
> wrote:
>>
>> Hi Gail,
>>
>> personally I wouldn't expect the pessimistic lock to be dropped.
>> In case of optimistic locking, I would expect the version to be
>> updated to the l
Ah, I see.
Using H2, the lock is still held after calling EntityManager#refresh(Object
entity), in spite of Hibernate setting the lock mode to NONE for the
entity in the PersistenceContext.
On Wed, Jan 31, 2018 at 2:11 PM, Sanne Grinovero
wrote:
> On 31 January 2018 at 21:48, Gail Badner wrot
>
> It is possible to call EntityManager#lock(Object entity, LockModeType
> lockMode) with a lower-level lock, but that request will be ignored.
> Hibernate will only upgrade a lock.
>
Sure, this is in keeping with most (all?) databases - a transaction can
only acquire more restrictive locks.
>
It should not set NONE in the PC even. It should only overwrite if the new
lock mode is "greater than" the current one. For sure we used to have
these checks, but apparently no regression tests for it.
On Wed, Jan 31, 2018 at 4:55 PM Gail Badner wrote:
> Ah, I see.
>
> Using H2, the lock is s
OK, sounds good.
Thanks,
Gail
On Wed, Jan 31, 2018 at 2:38 PM, Steve Ebersole wrote:
> It is possible to call EntityManager#lock(Object entity, LockModeType
>> lockMode) with a lower-level lock, but that request will be ignored.
>> Hibernate will only upgrade a lock.
>>
>
> Sure, this is in kee
I am waiting until I hear back from Joel from Sonatype regarding disabling
the JBoss Nexus -> OSSRH sync for ORM artifacts before I can release.
On Wed, Jan 31, 2018 at 10:06 AM Guillaume Smet
wrote:
> On Wed, Jan 31, 2018 at 4:54 PM, Steve Ebersole
> wrote:
>
>> Yes, I agree. As it is, it is
22 matches
Mail list logo
