Re: [hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final

[Sanne Grinovero]

Thanks for the release Gail!
I did the Twitter announce; I'll leave the G+ task to someone familiar
with that.

(BTW we us twitter @Hibernate, not @hibernate-dev for announcements)
Did you have any issue with doing these?

Regarding the blog: it would be nice to mention which version was released ;)

Thanks,
Sanne

On 17 December 2015 at 06:02, Gail Badner  wrote:
> I could not announce on twitter @hibernate_dev or on Google+. Could someone
> please add those announcements please?
>
> Thanks,
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Infinispan versions for Hibernate OGM

[Radim Vansa]

On 12/16/2015 10:41 PM, Gunnar Morling wrote:
> Hi,
>
> Is there an actual need for 8.1 at this point (so does it provide
> features we really need in OGM?) or is this more a general/theoretical
> proposal?
>
> I like the idea in general, but we must carefully think through all
> the implications, such as what module slot to depend on in the OGM
> dialect and so on. I suppose the alias stuff may come in handy here.

I think that the most important part is being independent, than choosing 
the 'right' version. Infinispan 8.0 brought a few regressions 
performance-wise, and developers are actively working on fixing those 
(not sure how much of the effort landed in 8.1). 8.2 could bring quite 
interesting scalability (in terms of concurrently processed requests) 
improvements.

>
> Question on Remote: can the 8.0 libs in WF talk to a 8.1 remote?

Old HotRod client can always talk to new HotRod server. New HotRod 
client may require configuration setting (limiting certain features) in 
order to talk to old server.
In library=embedded mode, compatibility of different version in the same 
cluster is *not* guaranteed even for micro releases.

Radim

>
> All in all, if there is a strong benefit for going to the latest ISPN
> right now, let's do it, otherwise I'd prefer if we sticked for now to
> what's provided and focused on getting the remote dialect fly. Let's
> life out the module obsession once we actually gain something from it
> ;)
>
> --Gunnar
>
>
>
> 2015-12-16 14:04 GMT+01:00 Sanne Grinovero :
>> Hello all,
>>
>> we generally have been trying to target the versions of Infinispan
>> provided by the WildFly version we're targeting for compatibility with
>> a specific OGM release cycle.
>>
>> I would like to change that, and for example now switch to the latest
>> Infinispan 8.1.0.Final (rather than the one in WildFly 10 candidate
>> release, which would be 8.0.2.Final).
>>
>> Several reasons:
>>
>> # shall not use the WildFly Infinispan distribution
>>in WildFly the specific Infinispan version being integrated is an
>> implementation detail.
>> People wanting to use Infinispan directly, or for other means than the
>> ones addressed by the WildFly clustering features which are based on
>> Infinispan (but don't expose it), should be encouraged to download the
>> Infinispan modules from the Infinispan project. We should apply (and
>> encourage) this practice too.
>>
>> # pick our own version
>>it's obviously nicer for us to reserve ourselves the practical
>> benefits of being able to pick our own version according to needs,
>> rather than stick with wathever WildFly requires.
>>
>> # we might have a need for latest Infinispan
>>probably no need to explain ;)
>> I don't with us to wait for an app-server update cycle when we need an
>> upstream patch.
>>
>> # don't aim at a single WildFly version
>>while we're currently running integration tests with latest WildFly,
>> I think it's desirable to use that as a testing bed for the modules we
>> provide but not as a coupling factor for our dependency matrix.
>> In other words, let's prepare OGM to be able to produce modules for
>> different versions of the application servers (and not least other
>> application servers although that's unrelated).
>> Not least, the fact that the app server is sticking with some version
>> shouldn't have an impact to all of our users who have no interest in
>> this particular appserver at all.
>>
>> Am I missing any important counter argument?
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Forum changes proposal

[Steve Ebersole]

FYI...
http://meta.stackoverflow.com/questions/312708/stackoverflow-teams-sign-up


On Thu, Dec 10, 2015 at 3:07 PM Steve Ebersole  wrote:

> I just sent the request.
>
>
> On Thu, Dec 10, 2015 at 12:26 PM Sanne Grinovero 
> wrote:
>
>> On 10 December 2015 at 17:48, Steve Ebersole  wrote:
>> > On Thu, Dec 10, 2015 at 11:43 AM Sanne Grinovero 
>> > wrote:
>> >>
>> >> On 10 December 2015 at 15:24, Steve Ebersole 
>> wrote:
>> >> > BTW, there is already a hibernate-users mailing list hosted on the
>> JBoss
>> >> > Mailman instance.  Back when we moved to JBoss Mailman they used to
>> set
>> >> > up a
>> >> > number of lists by default.  We just chose to not really use this
>> one in
>> >> > particular.  We could use this one for purpose discussed here.
>> >>
>> >> Yes, that would be nice. I'm registered on that list, and there have
>> >> been questions already although they are extremely rare - I recall
>> >> something like 3 a year? - probably because I don't think its
>> >> existance was ever advertised.
>> >
>> >
>> > Not sure.  Mailman is not great at showing "list statistics".  Actually
>> it
>> > kind of sucks as an archive (not searchable, segmented, etc).
>> >
>> > http://lists.jboss.org/pipermail/hibernate-users/
>> >
>> >
>> >> > BTW, I looked into creating a Hibernate SO Team.  Are we thinking one
>> >> > team?
>> >> > Or one per project (ORM, OGM, etc)?
>> >>
>> >> Depends on how it works? I do monitor various tags, including
>> >> "hibernate", "hibernate-search", "hibernate-ogm" and sometimes do a
>> >> cross-check query like "hibernate" + "lucene", although others on our
>> >> team often arrive first to answer.
>> >>
>> >> If the intent of the feature is to distribute the load among people to
>> >> answer and monitor such tags, then I guess you're not interested in
>> >> being notified for the Lucene related ones?
>> >>
>> >> From what I understand here:
>> >>  -
>> >>
>> http://meta.stackoverflow.com/questions/307513/the-power-of-teams-a-proposed-expansion-of-stack-overflow
>> >>
>> >> It looks like it's more about showing off our affiliation, and to
>> >> create a space were people can ask questions "about the team".
>> >> So I'd say a single team unless I misunderstood things.
>> >
>> >
>> > That would be my vote as well: one team
>>
>> Let's start with one then!
>> If future features warrant a more fine-grained approach for some
>> practicality reasons, we'll consider making sub-groups as an addition,
>> but I guess in terms of community it makes sense to build up a single
>> strong brand.
>>
>> Will you set it up?
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Forum changes proposal

[Hardy Ferentschik]

On Thu, Dec 17, 2015 at 01:06:14PM +, Steve Ebersole wrote:
> FYI...
> http://meta.stackoverflow.com/questions/312708/stackoverflow-teams-sign-up

Interesting. 

--Hardy



pgpejtNbnxaR7.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Pooled Optimiser Improvements

[Scott Marlow]

A few more code changes are needed for the optimiser optimiser.

On 12/16/2015 11:04 AM, Steve Ebersole wrote:
> Well keeping in mind that IMO this should be a separate optimizer (I
> know I won't be the only one to be leery of ThreadLocals here), users
> should be able to specify this one explicitly at the
> generator-definition site.
>
> Of course not all use cases allow explicitly specifying this, which is
> sort of what you are getting at.
>   `hibernate.id.optimizer.pooled.prefer_lo` was the initial attempt at
> such use cases based on the original optimizers.  At the end of the day
> we are really just trying to determine the default optimizer to use when
> one was not explicitly specified.  Previously this was just a choice
> between POOLED and POOLED_LO (hence the boolean).  Stuart is bringing up
> a new suggestion in this decision point.  Really I think the best option
> is simply to allow the user to specify the default pooled optimizer they
> want to use : POOLED, POOLED_LO, POOLED_LOTL (fugly name).
>
> I see your latest reply now Scott.  And I don't think that changing a
> previously boolean setting to now accept Optimizer names is the correct
> solution.  I think we leave hibernate.id.optimizer.pooled.prefer_lo as
> is, although possibly deprecate it.  We'd add a new config setting for
> this: `hibernate.id.optimizer.pooled.preferred`.  If not set we fallback
> to `hibernate.id.optimizer.pooled.prefer_lo` and what we do today.
>
>
>
> On Wed, Dec 16, 2015 at 8:24 AM Scott Marlow  > wrote:
>
>
>
> On 12/16/2015 09:07 AM, Scott Marlow wrote:
>  > Any arguments against merging the
>  >
> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>  > change to master + 5.x?
>  >
>  > I will create a jira for this change.
>
> HHH-10381
>
>  >
>  > Any suggestions for how to specify in persistence.xml, that the
>  > PooledThreadLocalLoOptimizer should be used?  We already have
>  > "hibernate.id.optimizer.pooled.prefer_lo", which I think can be
> true or
>  > false.  Should we add another another similar property?  Or perhaps
>  > allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
>  > thread local optimizer" or "pooled-lotl"?  Something like:
>  >
>  >   > value="pooled-lotl"/>
>  >
>  >
>  > On 12/15/2015 09:01 PM, Stuart Douglas wrote:
>  >> With my original patch the intention was that that the thread
> local blocks were smaller than the incrementSize, so not every
> thread local allocation would require a DB call. Your patch changes
> that approach but I don't think it actually matters that much, the
> overall performance should still be similar, and it has the
> advantage of not needed an extra configuration value.
>  >>
>  >> Stuart
>  >>
>  >> - Original Message -
>  >>> From: "Scott Marlow"  >
>  >>> To: "Steve Ebersole"  >, "Stuart Douglas"  >, hibernate-dev@lists.jboss.org
> 
>  >>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
>  >>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>  >>>
>  >>>
> https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>  >>> is looking more correct now, if others want to look at that.
>  >>>
>  >>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
>  
>  
>   On 12/15/2015 05:58 PM, Scott Marlow wrote:
>  >
>  >
>  > On 12/15/2015 05:40 PM, Scott Marlow wrote:
>  >> I changed the new test methods a bit.  [2] seems to be
> passed the tests
>  >> but I am not understanding how PooledThreadLocalLoOptimizer
> should
>  >> coordinate with the AccessCallback to allocate the next chunk of
>  >> sequence numbers.
>  >>
>  >> We seem to be able to call AccessCallback.getNextValue() to
> get the next
>  >> available sequence number but how do we reserve a block of
> 5000 sequence
>  >> ids?  Am I supposed to call callback.getNextValue() an extra
> time to get
>  >> a range of values?  Is there a separate database transaction
> that is
>  >> used by the AccessCallback.getNextValue() calls?  I'm
> missing something.
>  >
>  > Thinking more about this, I assume that
> AccessCallback.getNextValue() is
>  > operating under a database transaction that we are probably
> ending
>  > before AccessCallback.getNextValue() returns.  It also sounds
> like the
>  > database table is tracking the "lo" value, as mentioned in the
>  > PooledLoOptimizer.  This implies that only the application
> layer knows
>  > what the range is.  This seems like an important dependen

Re: [hibernate-dev] Lucene 5.4 available: include it in a micro release?

[Sanne Grinovero]

Ok that was probably a foolish idea, especially like I'm realising
there wouldn't be a version range available like Guillaume Smet
suggests for people needing Lucene 5.3 but with additional fixes from
us.

Guillaume: still, this Lucene version could have equally been a
"micro"- if you except that Boost method set which is quite surprising
they removed them without even a single deprecation iteration. That
led me to think that it's probably not widely used.
Anyway: be aware that you could test Lucene 5.4 as a drop-in
replacement for 5.3, in case you're interested.

Andrej: are you needing that upgrade soon? Any interesting reasons?

If so we could already publish a quick Alpha version of 5.6: I'd label
it Alpha not because I think it's not stable but because the new
features which we're working on for 5.6 are not working yet; so as
long as you don't use them it should be fairly similar to an upgraded
5.5.x

Let us know ;)

Thanks,
Sanne


On 16 December 2015 at 19:18, Gunnar Morling  wrote:
> I'd prefer us to do this in a minor version, i.e. 5.6.
>
> As we expose Query to users, the removal of these methods may cause
> compilation errors on their side. Also the deprecation of Filter may
> cause many deprecations in client code.
>
> Both seem not appropriate for a micro release to me.
>
> I don't think we need to rush it. Compared to previous times, we are
> keeping up with new Lucene versions closely these days, so doing it
> during the envisioned 5.6 time frame seems fast enough to me. Or, if
> you really want to get it out sooner, we can do a quick 5.6 off
> master, I suppose prior to those first ES commits and release the
> latter as 5.7.
>
> --Gunnar
>
>
>
>
> 2015-12-16 14:22 GMT+01:00 Sanne Grinovero :
>> Hello all,
>>
>> Apache Lucene 5.4.0 is released as stable, and while it includes
>> several benefits - not least a performance fix from myself which I'd
>> be keen to take advantage of - there are no significant changes
>> visible to end users, expect I think this one is worth a warning:
>>
>>  LUCENE-6590: Query.setBoost(), Query.getBoost() and Query.clone() are
>> gone. In order to apply boosts, you now need to wrap queries in a
>> BoostQuery.
>>
>> Although, it doesn't affect any of our code not examples so a release
>> note might be acceptable.
>>
>> There are several other interesting performance improvements.
>> So I'm tempted to upgrade to this version in the next maintenance
>> (micro) release of Hibernate Search 5.5.
>>
>> What do you all think about that?
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Trouble announcing Hibernate ORM 5.0.6.Final

[Gail Badner]

I had no problem logging onto @hibernate. I saw Vlad's tweet there already,
so didn't explicitly send a tweet from there.

Thanks for mentioning about the version number. I edited the blog to
explicitly state the version number.

On Thu, Dec 17, 2015 at 12:37 AM, Sanne Grinovero 
wrote:

> Thanks for the release Gail!
> I did the Twitter announce; I'll leave the G+ task to someone familiar
> with that.
>
> (BTW we us twitter @Hibernate, not @hibernate-dev for announcements)
> Did you have any issue with doing these?
>
> Regarding the blog: it would be nice to mention which version was released
> ;)
>
> Thanks,
> Sanne
>
> On 17 December 2015 at 06:02, Gail Badner  wrote:
> > I could not announce on twitter @hibernate_dev or on Google+. Could
> someone
> > please add those announcements please?
> >
> > Thanks,
> > Gail
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Lucene 5.4 available: include it in a micro release?

[Andrej Golovnin]

Hi Sanne,

> On 17.12.2015, at 17:11, Sanne Grinovero  wrote:
> 
> Ok that was probably a foolish idea, especially like I'm realising
> there wouldn't be a version range available like Guillaume Smet
> suggests for people needing Lucene 5.3 but with additional fixes from
> us.
> 
> Guillaume: still, this Lucene version could have equally been a
> "micro"- if you except that Boost method set which is quite surprising
> they removed them without even a single deprecation iteration.

The methods Query.setBoost() and Query.getBoost() were not removed.
They are marked as deprecated. Please read the JavaDocs
(http://lucene.apache.org/core/5_4_0/core/org/apache/lucene/search/Query.html)
and/or source code.

> Andrej: are you needing that upgrade soon? Any interesting reasons?

I don’t need it soon. And I’m just interested in performance improvements.

Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev