Re: [hibernate-dev] ORM progress: tricky branch state
+1 from me as well. On 07/02/2018 05:43 PM, andrea boriero wrote: > +1 for 5.3 branch > > On Mon, 2 Jul 2018, 19:05 Gail Badner, wrote: > >> +1 on creating a 5.3 branch, with master being used for 5.4 (or 6.0). >> >> On Mon, Jul 2, 2018 at 9:43 AM, Sanne Grinovero >> wrote: >> >>> On Mon, 2 Jul 2018 at 17:34, Steve Ebersole wrote: I don't mind creating a 5.3 branch, and having master for "after 5.3" >>> development with 6.0 hopefully merged in there soon. >>> >>> +1 that sounds like the best option we have. It's not extremely >>> urgent, we can do this after 5.3.2 ? >>> >>> Just making sure we tighten up the process a bit when we start merging >>> all "compatibility fixes" in WildFly 14, yet not too soon to not waste >>> too much time backporting everything. >>> >>> Thanks! >>> Sanne >>> On Mon, Jul 2, 2018 at 11:23 AM Steve Ebersole >>> wrote: > I think I have pointed out before that such a schedule is already >>> posted : https://github.com/sebersole/hibernate-core/blob/wip/6.0/ >>> design/6.0-todo.adoc#alpha1 > The important part remaining is really collection support. > > There are a few listed there that we'd be willing to push to the next >>> Alpha > On Mon, Jul 2, 2018 at 10:42 AM Sanne Grinovero >>> wrote: >> On Hibernate ORM we're currently having "master" branch essentially >> being a maintenance branch, aka master today is what's planned to be >> version 5.3.2.Final in some days, 5.3.3 later, etc.. >> >> This is quite unusual, and it begs some extra attention: normally >> we'd >> start a new minor in master, so that PRs of any kind could be welcome >> in master, while specific, cherry-picked fixes are backported to the >> last maintained minors. >> >> This is not the case now and until we move on to a new minor or major >> we'll need to be particularly careful about what is allowed to be >> merged. >> I'm not pointing fingers to any specific commit, my concern is just >> raised by the high volume of changes being merged. They all look >> great >> individually but changes are not good at this point :) >> >> Not sure what to suggest to people wanting to contribute new features >> today; maybe hold as we assume the 6.0 work will be merged in master >> soon? Will be hard to say no to many reasonable requests though. >> >> Steve, do you think that the 6.0 merge could happen soon enough to >> not >> need any process changes in how we deal with master? >> >> 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 >> > ___ > 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
[hibernate-dev] NoORM IRC meeting minutes
Hi! Here are the minutes of this week's NoORM IRC meeting: 15:20 < jbott> Meeting ended Tue Jul 3 13:20:30 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:20 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-03-13.00.html 15:20 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-03-13.00.txt 15:20 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-07-03-13.00.log.html Cheers, -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3 cache issues [Requires Steve]
I think they are afraid of you Steve :D When asking, we could make it clear where we stand: - I feel unsure and need someone else to back me up, ideally the project lead - I think I'm right but let's see if Steve or other knowledgable person comes with a strong argument against - I don't want to make the decision, whatever someone else decides At least it gives the right frame of thinking to the person answering. Emmanuel On Mon 18-07-02 18:03, Steve Ebersole wrote: >Then not sure why you ask if you already plan on your answer ;) > >On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet >wrote: > >> On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole wrote: >> >>> 1) That was specifically requested >>> >> >> Sure. And we also have users who are unhappy with the new setup. >> >> This was also changed for the legacy Ehcache 2 provider which is a pity >> IMHO. >> >> >>> 2) This is easily handled by the providers, if they wish. They would >>> simply map any undefined regions/caches to a pre-defined one (probably >>> after warning the user). Keep in mind that region != cache. A provider >>> might map multiple region names to a single cache. That was always the >>> case, but every provider mapped region <-> cache as 1-1 - the new API makes >>> this much more clear. >>> >>> Personally I think that not allowing on-the-fly creation is a good idea, >>> though maybe it can be made configurable. >>> >> >> Well, the fact is that it can be a perfectly valid setup if you have >> defined a default template for your caches. Typically, as explained here: >> https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080 >> or in the Ehcache documentation for JCache. >> >> If I have 500 entities, using the default default JCache provider, I have >> to define the configuration for these 500 caches (+ the ones for the >> collections). Whereas I could use a template for most of them. Note that >> this is not a rhetorical position: we did that for all our applications >> with Yoann at our previous job: sane default cache + fine tuning for >> specific entities. >> >> My personal opinion is that we should have a warning explaining the >> situation and the frameworks could choose to throw an error if they see fit >> but I don't think the default setup should be to throw an error. >> >> Apart from the valid default template case, not being to start your >> application until all your caches are configured doesn't seem very helpful >> when you are developing your application. You don't start your development >> by fine tuning all your caches: it's something you usually do before >> pushing your app to production and then adjust with the feedback you have >> from the field. >> >> And if you want to be sure, when you push it to production, you can use >> the new configuration property Yoann introduced in his PR to make it fail. >> >> -- >> Guillaume >> >___ >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] 5.3 cache issues [Requires Steve]
On Tue, Jul 3, 2018 at 5:11 AM Yoann Rodiere wrote: > 2) This is easily handled by the providers, if they wish. They would >> simply map any undefined regions/caches to a pre-defined one (probably >> after warning the user). Keep in mind that region != cache. A provider >> might map multiple region names to a single cache. That was always the >> case, but every provider mapped region <-> cache as 1-1 - the new API >> makes >> this much more clear. > > > Just to clarify: this would require cache implementors to provide their > own region factory, and in that case we all agree they can do whatever they > want, which is nice. > > The problem is more with the built-in Ehcache and JCache region factories. > Our built-in region factories call getCache(String), and if it returns > null, they throw an exception. So the cache implementors do not have an > easy way to auto-create a cache using some internal, default configuration: > they would have to do that in the getCache(String) method, and it's > arguably not something you want to do in a method with such a name, > especially considering it's exposed to other clients than just Hibernate > ORM. And I'm not sure the JCache specification even allows that. > > Ideally we'd like Ehcache/JCache to expose some getOrCreate(String) > method, and decide for themselves whether to throw an exception or not, but > well... they don't. Which explains the suggestion to handle the "default" > logic on our end. > Not sure exactly what you expect this to return - that's the problem. It would need to return a `net.sf.ehcache.Cache` or a `javax.cache.Cache` or a ... So I think you need to split this into a discussion about Ehcache and one about JCache. For Ehcache... whatever. As I keep saying, that provider is based on Ehcache 2 which the Ehcache team hasn't supported for years now. People really should not be using that one. If you want to revert that one, that's fine For JCache, as I have already said, I am fine with adding a setting here to allow on-the-fly creations. On-the-fly creations are a terrible idea, but people can chose that option if they wish. Just make sure that any logging here (especially the "we are creating an on-the-fly Cache for you") happens through `org.hibernate.cache.spi.SecondLevelCacheLogger` ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 5.3 cache issues [Requires Steve]
> > 2) This is easily handled by the providers, if they wish. They would > simply map any undefined regions/caches to a pre-defined one (probably > after warning the user). Keep in mind that region != cache. A provider > might map multiple region names to a single cache. That was always the > case, but every provider mapped region <-> cache as 1-1 - the new API makes > this much more clear. Just to clarify: this would require cache implementors to provide their own region factory, and in that case we all agree they can do whatever they want, which is nice. The problem is more with the built-in Ehcache and JCache region factories. Our built-in region factories call getCache(String), and if it returns null, they throw an exception. So the cache implementors do not have an easy way to auto-create a cache using some internal, default configuration: they would have to do that in the getCache(String) method, and it's arguably not something you want to do in a method with such a name, especially considering it's exposed to other clients than just Hibernate ORM. And I'm not sure the JCache specification even allows that. Ideally we'd like Ehcache/JCache to expose some getOrCreate(String) method, and decide for themselves whether to throw an exception or not, but well... they don't. Which explains the suggestion to handle the "default" logic on our end. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On Tue, 3 Jul 2018 at 01:04, Steve Ebersole wrote: > Then not sure why you ask if you already plan on your answer ;) > > On Mon, Jul 2, 2018 at 5:48 PM Guillaume Smet > wrote: > > > On Mon, Jul 2, 2018 at 9:15 PM Steve Ebersole > wrote: > > > >> 1) That was specifically requested > >> > > > > Sure. And we also have users who are unhappy with the new setup. > > > > This was also changed for the legacy Ehcache 2 provider which is a pity > > IMHO. > > > > > >> 2) This is easily handled by the providers, if they wish. They would > >> simply map any undefined regions/caches to a pre-defined one (probably > >> after warning the user). Keep in mind that region != cache. A provider > >> might map multiple region names to a single cache. That was always the > >> case, but every provider mapped region <-> cache as 1-1 - the new API > makes > >> this much more clear. > >> > >> Personally I think that not allowing on-the-fly creation is a good idea, > >> though maybe it can be made configurable. > >> > > > > Well, the fact is that it can be a perfectly valid setup if you have > > defined a default template for your caches. Typically, as explained here: > > > https://hibernate.atlassian.net/browse/HHH-11953?focusedCommentId=102080=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-102080 > > or in the Ehcache documentation for JCache. > > > > If I have 500 entities, using the default default JCache provider, I have > > to define the configuration for these 500 caches (+ the ones for the > > collections). Whereas I could use a template for most of them. Note that > > this is not a rhetorical position: we did that for all our applications > > with Yoann at our previous job: sane default cache + fine tuning for > > specific entities. > > > > My personal opinion is that we should have a warning explaining the > > situation and the frameworks could choose to throw an error if they see > fit > > but I don't think the default setup should be to throw an error. > > > > Apart from the valid default template case, not being to start your > > application until all your caches are configured doesn't seem very > helpful > > when you are developing your application. You don't start your > development > > by fine tuning all your caches: it's something you usually do before > > pushing your app to production and then adjust with the feedback you have > > from the field. > > > > And if you want to be sure, when you push it to production, you can use > > the new configuration property Yoann introduced in his PR to make it > fail. > > > > -- > > Guillaume > > > ___ > 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
