[hibernate-dev] Needing and ORM 5.1.1.Final
Hi all, we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM.. could we plan for one soon please? Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] People can't find our docs
I'll try to apply these changes on Friday. Davide On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet wrote: > Hi Sanne, > > Thanks for your feedback. I was pretty sure I hadn't all the history! > > Getting Google to prioritize our latest doc is probably a long time goal. > > I played a bit with jQuery to suggest to the user to go to the latest > stable. Note that I only took into consideration the page for the time > being and didn't consider the anchor but it should be easy to add it > if we think it's worth it (it's a lot more work on the json descriptor > though). > > The following command for each version is all that is needed: > sed -i 's@@ src="http://code.jquery.com/jquery-3.1.0.min.js"; > integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s=" > crossorigin="anonymous"> src="/hibernate/search/outdated-version.js">@' *.html > (or a find -exec to do it on all the versions at once) > > I attached the global json descriptor and the js file (with a .txt > extension as it didn't pass the mail filter). Both should be added to > /hibernate/search/. Note that I only did the work for version 4.5 in > the json descriptor. The work for other versions would mostly be a > copy/paste. > > I also attached a screenshot of how it looks like. Nothing fancy but > we can do whatever we want. > > Note that I only targeted the multi page HTML output as it was the > most interesting to prototype. > > When we release a new version, we would have to update the descriptor file. > > Comments? > > -- > Guillaume > > On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero wrote: >> Hi Guillaume, >> >> yes I'm aware of the issue; we discussed it before, I think on this >> same mailing list but maybe it was during our last meeting. >> >> We really need to fix that metadata; Stefania (my partner) is an SEO >> consultant and is shocked at how bad we do with this; apparently we >> are a funny example in her office but at least we're not the worst :) >> >> The problem is we can't change the headers as we don't control the >> Apache httpd configuraion on the documentation server, so the >> alternative is we'd need to rsync those docs locally, insert the right >> changes in the static files of the docs, and push them back. >> >> Needs a volunteer to find some time for this. >> >> Also related to SEO I recently opened some issues on our WEBSITE >> project, these should be easier to fix as it's directly under our >> control: >> - https://hibernate.atlassian.net/browse/WEBSITE-461 >> - https://hibernate.atlassian.net/browse/WEBSITE-460 >> - https://hibernate.atlassian.net/browse/WEBSITE-459 >> >> I've assigned them to Davide as he's usually quick with such things >> but anyone is welcome to take some. >> >> The metadata issue on the docs server is probably the most urgent / >> valuable though. >> >> 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] Needing and ORM 5.1.1.Final
Sanne - I'm under the impression that Gail has plans to do a 5.0.10 / 5.1.1 late this week if all goes according to plan. Chris On 07/20/2016 04:36 AM, Sanne Grinovero wrote: > Hi all, > we're still needing a release of Hibernate ORM 5.1.1 for Hibernate OGM.. > > could we plan for one soon please? > > 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] [ORM] EhCache 3 and JCache
Hi Guys, Is it possible to use EhCache 3.x with Hibernate 5.2 ? Many Thanks, Noel On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet wrote: Hi, I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386 I'll be looking at the test referenced by Radim over the next days to see what can be done. Regards, Louis On Wed, May 25, 2016 at 9:52 AM Radim Vansa wrote: > It would be very nice if different implemenations could share parts of > the testsuite, no doubts about that. > > TCK (or functional tests) is useful to find out cases when the > implementation does not adhere to specification (which is 'always return > the same thing DB would' in the modes but nonstrict-rw). However, race > conditions are different matter. From my experience a stress test that > the developer runs for a couple of hours is more likely to hit race > conditions, that won't show up in functional testsuite. It's possible > that there would be less issues due to EhCache's locking nature of the > implementation, though. And if the code is meant to be run in clustered > environment, it has to be tested that way, as distributed systems tend > to behave in unexpected manners. > > I've written a stress test [1] that covers the basic operations but > don't take it as "passed => it's correct". I've tweaked the parameters > (most notably NUM_FAMILIES) and probabilities of operations (e.g. > removing the InvalidateCache as this breaks many transactions) to > manifest different situations. Also, it's important to test with both H2 > 1.3 and H2 1.4 as these use different locking semantics, leading to > races or deadlocks. > > It shouldn't be hard to reuse most of it - Infinispan specific code > deals only with test setup and then introduces random failures in the > operations (as RPC/locking timeouts or other errors happen in a > distributed system). Trying to reuse the functional testsuite will be > more time-demanding task. > > Radim > > [1] > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java > > On 05/25/2016 01:24 AM, Steve Ebersole wrote: > > Master is 5.2. There was a previous discussion on this list detailing > the > > 5.2 changes. Where possible we did not change APIs (though there were a > > few cases where that was needed to avoid clashes with JPA method names). > > We did change lots of SPIs though. > > > > If you are willing to commit to getting this to us early next week, I > > commit to reviewing the PR. I'd feel most comfortable if Sanne looked it > > over as well. > > > > Also, I do think it would be worthwhile to investigate a "cache provider > > tck". Radio, thoughts? > > > > On Tue, May 24, 2016, 4:27 PM Louis Jacomet wrote: > > > >> Hey Steve, > >> > >> That's a tough question. > >> For tomorrow I don't see how ... Technically the code is out there. But > it > >> lacks documentation which is needed: how to select a specific provider > and > >> specify a URI which can be used as config source. That still needs to be > >> added. > >> > >> In one week, more likely. I am willing to commit on having it all in > >> proper shape. > >> > >> Which branch will 5.2 be cut from? Because when I last checked some > >> changes happened in master that impacted api but seem to be identified > as > >> 6.0 related. > >> > >> What are the chances someone from the hibernate side can look at it in > >> this timeframe? To make sure nothing dumb slips through. > >> > >> Regards, > >> Louis > >> > >> > >> On mar. 24 mai 2016 at 22:57, Steve Ebersole > wrote: > >> > >>> https://hibernate.atlassian.net/browse/HHH-10770 > >>> > >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole > >>> wrote: > >>> > Hi Louis, > > In my opinion, > > - Yes, of course :) > - The plan is to release 5.2 tomorrow. So either this would have > to > be done tomorrow or the release date pushed back in order for > this to be > part of 5.2. We could push 5.2 another week, but would the work > for this > be done in a week? > > > On Tue, May 24, 2016 at 3:39 PM Louis Jacomet > wrote: > > > Hello, > > > > I have a couple questions: > > * Should there be an issue created to track this work? > > * On which branch should this work based if we target a release with > > 5.2? > > > > In parallel, I have been reading the pointers Vlad gave and I intend > to > > verify the current code actually works in all these cases :-) Any > chance > > there exist some kind of test suite for L2 caching providers? > > > > Regards, > > Louis > > > > On Fri, May 20, 2016 at 3:41 PM Steve Ebersole > > wrote: > > > >> What we had decided before during a discussion with myself, Alex > Snaps, > >> Radim and Sanne was to develop a JCache-based L2 case module and > that > >> Ehcache 3 would be supported
Re: [hibernate-dev] 6.0 - Type redesign
I just read it. Some random remarks. Small correction on the description of the legacy Type also offers a navigation on the cardinality and knowledge of the Hibernate structures like assocaitions (one to one etc), component, any etc and mutability. But that’s minor and all covered by your proposal. BasicType does not handle multiple column and compositeType is the mebedded case. How would multi-column types would be handled? Positional types only, not named columns: that is likely going to impact OGM and it needs to play well with that new approach. Guillaume or Davide, if you ahve 30 mins to spare, that might be interesting to check how the GridType could cope with positional parameters and not named columns for “nullSafeSet / Get calls" Why do you need to ”unscope" the TypeConfiguration? What do you gain from it? I’m trying to picture a reuse use case? Methods of Type needing Session: I used to call them passing null in some old code and hoping for the best. Are the reasons for using Session still present? Would be nice to get rid of that. On the genericization of Type, it would be extremely nice indeed for OGM, but it would require to genericize SqlTypeDescriptor and its methods essentially. Not necessarily super trivial. > On 22 Jun 2016, at 18:54, Steve Ebersole wrote: > > I started a wiki discussing the proposal for the type system redesign. > Let's get discussions about it starter sooner rather than later. Thanks! > > https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign > ___ > 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] [ORM] EhCache 3 and JCache
Hi Noel, Yes this is available in Hibernate 5.2. Have a look at http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#caching-provider-jcache You can of course use Ehcache 3.x as the JCache implementation - for which documentation is available at http://www.ehcache.org/documentation/3.1/107.html but does not cover any hibernate specifics. And of course, it should work for any JCache provider out there. Regards, Louis On Wed, Jul 20, 2016 at 7:21 PM Noel Diaz wrote: > Hi Guys, > > Is it possible to use EhCache 3.x with Hibernate 5.2 ? > > Many Thanks, > > Noel > > > > On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet > wrote: > > > Hi, > > I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386 > > I'll be looking at the test referenced by Radim over the next days to see > what can be done. > > Regards, > Louis > > On Wed, May 25, 2016 at 9:52 AM Radim Vansa wrote: > > > It would be very nice if different implemenations could share parts of > > the testsuite, no doubts about that. > > > > TCK (or functional tests) is useful to find out cases when the > > implementation does not adhere to specification (which is 'always return > > the same thing DB would' in the modes but nonstrict-rw). However, race > > conditions are different matter. From my experience a stress test that > > the developer runs for a couple of hours is more likely to hit race > > conditions, that won't show up in functional testsuite. It's possible > > that there would be less issues due to EhCache's locking nature of the > > implementation, though. And if the code is meant to be run in clustered > > environment, it has to be tested that way, as distributed systems tend > > to behave in unexpected manners. > > > > I've written a stress test [1] that covers the basic operations but > > don't take it as "passed => it's correct". I've tweaked the parameters > > (most notably NUM_FAMILIES) and probabilities of operations (e.g. > > removing the InvalidateCache as this breaks many transactions) to > > manifest different situations. Also, it's important to test with both H2 > > 1.3 and H2 1.4 as these use different locking semantics, leading to > > races or deadlocks. > > > > It shouldn't be hard to reuse most of it - Infinispan specific code > > deals only with test setup and then introduces random failures in the > > operations (as RPC/locking timeouts or other errors happen in a > > distributed system). Trying to reuse the functional testsuite will be > > more time-demanding task. > > > > Radim > > > > [1] > > > > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java > > > > On 05/25/2016 01:24 AM, Steve Ebersole wrote: > > > Master is 5.2. There was a previous discussion on this list detailing > > the > > > 5.2 changes. Where possible we did not change APIs (though there were > a > > > few cases where that was needed to avoid clashes with JPA method > names). > > > We did change lots of SPIs though. > > > > > > If you are willing to commit to getting this to us early next week, I > > > commit to reviewing the PR. I'd feel most comfortable if Sanne looked > it > > > over as well. > > > > > > Also, I do think it would be worthwhile to investigate a "cache > provider > > > tck". Radio, thoughts? > > > > > > On Tue, May 24, 2016, 4:27 PM Louis Jacomet > wrote: > > > > > >> Hey Steve, > > >> > > >> That's a tough question. > > >> For tomorrow I don't see how ... Technically the code is out there. > But > > it > > >> lacks documentation which is needed: how to select a specific provider > > and > > >> specify a URI which can be used as config source. That still needs to > be > > >> added. > > >> > > >> In one week, more likely. I am willing to commit on having it all in > > >> proper shape. > > >> > > >> Which branch will 5.2 be cut from? Because when I last checked some > > >> changes happened in master that impacted api but seem to be identified > > as > > >> 6.0 related. > > >> > > >> What are the chances someone from the hibernate side can look at it in > > >> this timeframe? To make sure nothing dumb slips through. > > >> > > >> Regards, > > >> Louis > > >> > > >> > > >> On mar. 24 mai 2016 at 22:57, Steve Ebersole > > wrote: > > >> > > >>> https://hibernate.atlassian.net/browse/HHH-10770 > > >>> > > >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole > > >>> wrote: > > >>> > > Hi Louis, > > > > In my opinion, > > > > - Yes, of course :) > > - The plan is to release 5.2 tomorrow. So either this would have > > to > > be done tomorrow or the release date pushed back in order for > > this to be > > part of 5.2. We could push 5.2 another week, but would the work > > for this > > be done in a week? > > > > > > On Tue, May 24, 2016 at 3:39 PM Louis Jacomet > > wrote: > > > > > Hello, > >
Re: [hibernate-dev] [ORM] EhCache 3 and JCache
Thank you very much for the quick reply! Noel On Wednesday, July 20, 2016 2:18 PM, Louis Jacomet wrote: Hi Noel, Yes this is available in Hibernate 5.2. Have a look at http://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/Hibernate_User_Guide.html#caching-provider-jcache You can of course use Ehcache 3.x as the JCache implementation - for which documentation is available at http://www.ehcache.org/documentation/3.1/107.html but does not cover any hibernate specifics. And of course, it should work for any JCache provider out there. Regards,Louis On Wed, Jul 20, 2016 at 7:21 PM Noel Diaz wrote: Hi Guys, Is it possible to use EhCache 3.x with Hibernate 5.2 ? Many Thanks, Noel On Wednesday, May 25, 2016 6:51 AM, Louis Jacomet wrote: Hi, I have opened the PR: https://github.com/hibernate/hibernate-orm/pull/1386 I'll be looking at the test referenced by Radim over the next days to see what can be done. Regards, Louis On Wed, May 25, 2016 at 9:52 AM Radim Vansa wrote: > It would be very nice if different implemenations could share parts of > the testsuite, no doubts about that. > > TCK (or functional tests) is useful to find out cases when the > implementation does not adhere to specification (which is 'always return > the same thing DB would' in the modes but nonstrict-rw). However, race > conditions are different matter. From my experience a stress test that > the developer runs for a couple of hours is more likely to hit race > conditions, that won't show up in functional testsuite. It's possible > that there would be less issues due to EhCache's locking nature of the > implementation, though. And if the code is meant to be run in clustered > environment, it has to be tested that way, as distributed systems tend > to behave in unexpected manners. > > I've written a stress test [1] that covers the basic operations but > don't take it as "passed => it's correct". I've tweaked the parameters > (most notably NUM_FAMILIES) and probabilities of operations (e.g. > removing the InvalidateCache as this breaks many transactions) to > manifest different situations. Also, it's important to test with both H2 > 1.3 and H2 1.4 as these use different locking semantics, leading to > races or deadlocks. > > It shouldn't be hard to reuse most of it - Infinispan specific code > deals only with test setup and then introduces random failures in the > operations (as RPC/locking timeouts or other errors happen in a > distributed system). Trying to reuse the functional testsuite will be > more time-demanding task. > > Radim > > [1] > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java > > On 05/25/2016 01:24 AM, Steve Ebersole wrote: > > Master is 5.2. There was a previous discussion on this list detailing > the > > 5.2 changes. Where possible we did not change APIs (though there were a > > few cases where that was needed to avoid clashes with JPA method names). > > We did change lots of SPIs though. > > > > If you are willing to commit to getting this to us early next week, I > > commit to reviewing the PR. I'd feel most comfortable if Sanne looked it > > over as well. > > > > Also, I do think it would be worthwhile to investigate a "cache provider > > tck". Radio, thoughts? > > > > On Tue, May 24, 2016, 4:27 PM Louis Jacomet wrote: > > > >> Hey Steve, > >> > >> That's a tough question. > >> For tomorrow I don't see how ... Technically the code is out there. But > it > >> lacks documentation which is needed: how to select a specific provider > and > >> specify a URI which can be used as config source. That still needs to be > >> added. > >> > >> In one week, more likely. I am willing to commit on having it all in > >> proper shape. > >> > >> Which branch will 5.2 be cut from? Because when I last checked some > >> changes happened in master that impacted api but seem to be identified > as > >> 6.0 related. > >> > >> What are the chances someone from the hibernate side can look at it in > >> this timeframe? To make sure nothing dumb slips through. > >> > >> Regards, > >> Louis > >> > >> > >> On mar. 24 mai 2016 at 22:57, Steve Ebersole > wrote: > >> > >>> https://hibernate.atlassian.net/browse/HHH-10770 > >>> > >>> On Tue, May 24, 2016 at 3:51 PM Steve Ebersole > >>> wrote: > >>> > Hi Louis, > > In my opinion, > > - Yes, of course :) > - The plan is to release 5.2 tomorrow. So either this would have > to > be done tomorrow or the release date pushed back in order for > this to be > part of 5.2. We could push 5.2 another week, but would the work > for this > be done in a week? > > > On Tue, May 24, 2016 at 3:39 PM Louis Jacomet > wrote: > > > Hello, > > > > I have a couple questions: > > * Should there be an issue created to track this work? > > * On which branch should thi
