From rvansa at redhat.com Tue Apr 3 06:13:45 2018 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 3 Apr 2018 12:13:45 +0200 Subject: [hibernate-dev] Why hibernate-jcache is not enough (for Infinispan) In-Reply-To: References: <39e8c62e-12f2-5a0c-de06-3a907eace91f@redhat.com> Message-ID: <983058a2-24dc-fe12-d721-a96041df3c23@redhat.com> On 03/29/2018 02:11 PM, Steve Ebersole wrote: > Thanks for the thoughts Radim. > > But I think that there is a misunderstanding.. > > Today (pre-5.3) Hibernate has a hibernate-infinispan module that > integrates Infinispan into Hibernate ORM as a second-level cache.? In > fact it provides 2 integrations: `InfinispanRegionFactory` and > `JndiInfinispanRegionFactory`. And then inside WildFly there is (at > least) a third one specific to running inside WildFly.? Inside WildFly > is irrelevant... I say that because inside WildFly we are going to use > whatever the Infinispan team develops as infinispan-hibernate-cache.? > Which leaves the other 2.? The only thing (I believe) that > `InfinispanRegionFactory` and `JndiInfinispanRegionFactory` provide > over (and actually in any way different from) hibernate-jcache is > transactional access support, which you even say is going away. > > I understand about not being able to fully leverage > `CacheTransactionSynchronization` if hibernate-jcache is used.? IMO it > is the single drawback to using hibernate-jcache for Infinispan.? All > of the other things you mentioned are IMO implementation details.? > Well that and missing out on the new `DomainDataRegionConfig` stuff.? > And keep in mind that even hibernate-jcache offers some integration > points (thanks to Alex)... you can supply your own > `javax.cache.spi.CachingProvider` or `javax.cache.CacheManager` > directly to the RegionFactory for JCache.? So you have total control > still over how caches are built (sans access to `DomainDataRegionConfig`). > > So all-in-all I am still not understanding why `hibernate-jcache`?+ > `infinispan` is not enough for most cases.? Yes you miss out on some > possible performance improvements (leveraging > `CacheTransactionSynchronization` and `DomainDataRegionConfig` being > the 2 I can think of). Maybe I understand what hibernate-jcache is incorrectly. Infinispan exposes JCache API, and JCache dictates some behaviour. The behaviour with transactions is not specified and not tested by the JCache TCK. Hibernate-jcache consumes JCache API. I don't see any space for 'integration' besides dropping some configuration files (and that's the point, no code to maintain). My post was about the behaviour that can be optimized once we know the intent. JCache API is implemented according to the spec and does not express Hibernate's intent well enough. > However, that's why there is the possibility of a custom cache > provider - to leverage those things.? But again, taking a step back > and looking at the big picture... > > 1) We need to be able to run outside of WildFly.? The 2 legacy > `hibernate-infinispan` providers were intended for that. > 2) We need to be able to run inside of WildFly.? The provider supplied > with WildFly (Jipijapa) itself was intended for that. > > So how do we do that moving to 5.3?? As I mentioned above, I think we > can ignore "run inside of WildFly" for this discussion - that will > happen however Jipijapa says it will happen; if/when there is a > specific Infinispan-based 5.3 cache provider, Jipijapa will use that.? > It's more the "run outside of WildFly" case that I am talking about.? > So what are the things that we want to cover in Hibernate/Infinispan > caching combo?? AFAIK: > > 1. Transactional access support > 2. Cluster support (distributed versus replicated versus invalidated) > 3. Anything I am missing? > > So let's look at those 1-1: > > 1. You just said that you plan to drop transactional acccess support > anyway, so nothing to see here... > I've never said that I am dropping support for transactional *access*! org.hibernate.cache.spi.access.AccessType.TRANSACTIONAL will be always supported. We're dropping support for transactional *caches*. > 1. I may be wrong here, but I do not think that hibernate-infinispan > supported clustering (or at least very well) out-of-the-box.? At > least not based on the top google hits I saw for "hibernate > infinispan cluster". > Clustered support is default, you need to specify non-clustered configuration file via property if you don't want that one. > Given these points and the fact that Infinispan can (and would already > have to) implement JCache's `CachingProvider` / `CacheManager`, I > simply do not buy that `hibernate-jcache`?+ `infinispan` is any less > capable than the support we have today for Infinispan as a second > level cache.? Now, if you say that you want to develop a 5.3 provider > to actually make cluster setup easier, leverage > `CacheTransactionSynchronization` and/or other specific reasons.... > great, that is completely your prerogative and the reason this is all > still pluggable. > > P.S. JTA is a spec.? JTA components are accessible from a "well known > location" (aka, easily accessible by anyone).? So I really just do not > get your argument that `hibernate-jcache`?+ `infinispan` somehow loses > the ability to leverage JTA.? And btw this was absolutely not the > intent with `CacheTransactionSynchronization`, which was instead > intended to allow unified processing of "cache events" at the "end of > a transaction" (as known to Hibernate) regardless of whether JTA or > straight JDBC transactions are used. I have complained about JCache + JTA being undefined, nothing about leveraging JTA in our impl. > > P.S.S.? I totally agree with Sanne.? The cache should be as correct as > possible, however it is *always* possible to simply evict a piece of > data from the cache to avoid conflicts.? The database is *always* the > "truth of the system".? This in in fact exactly the principle that the > collection cache works - any changes to that collection simply > invalidate (evict) the data from the cache. When you simply evict a piece of data from the cache you can't be sure that that piece won't end up in there right away because another concurrent request holding stale data hits the cache again. R. > > > On Thu, Mar 29, 2018 at 3:03 AM Radim Vansa > wrote: > > Hi Steve, > > on HipChat you've asked why hibernate-jcache + Infinispan's > implementation of JCache is not enough. It ultimately boils down to > > 1. performance > 2. correctness > > where (2) can be fine with some providers but then (1) suffers. > Infinispan offers transactional mode, but it's not serializable (gosh, > sometimes it's even read_uncommitted) and has its quirks. The > performance can't be as good as with non-tx mode, too. That's why the > native transactional caches support will be dropped in 5.3 and we'll > just emit a warning to update their configuration (and continue with > non-tx config). > > As a demonstration of this we can use the putFromLoad. If you > implement > this as a (ideal serializable) transactional cache putIfAbsent, the > provider must either > a) lock the key (pessimistic approach) - but we don't want to block > other nodes removing data from the cache (on write) or putFromLoading > (on read!) > b) resolve conflicts when the transaction is committing: you > figure out > that there are two concurrent updates and rollback one of the > transactions - that's not acceptable to us either, as any failure in > cache should not affect DB transaction. And there's a risk of blocking > between the 2 phases of commit, too. > > Theoretically you could just wipe any modified data on conflict - I > don't know if anyone does that, 'drop everything and proceed with > commit' is not something I'd expect from a general-purpose (NoSQL) > DB. I > recall Alex's JCache implementation (for 5.2) storing some 'lock' > objects in the cache, and you probably don't want to wipe those. > > Interaction with evictAll/removeAll could be also problematic: not > sure > about the other providers but Infinispan's clear() operation is > non-transactional even on tx cache (since Infinispan 7 or so) because > it's impractical to resolve all conflicts. I don't know details how > others provide that operation but there may be a hidden problem. > > Last but not least, you assume that the provider is transactional > and it > provides JCache interface. JCache does not define interaction with > JTA, > because it was hard to get agreement on non-tx behaviour (why did it > take 13 years to complete the JSR?) and it would be even harder > for JTA. > So what you expect is just your extrapolation or wishful thinking, and > it's up to integrators to verify that the unwritten contract is > fulfilled within the scope of hibernate-jcache module use. Not > that SPI > implementors would be in a better position, but at least we are aware > that (for us) it's not enough to implement those 3 classes and > job's done. > > Of course the correctness aspect may be ignored with 'it's just a > cache' > implying 'users expect stale/uncommitted data' as Sanne (who is much > closer to the customers than me) keeps repeating. However this is not > what 2LC promises as I understand it: the same results as DB would do. > > I am really grateful that in 5.3 you've provided the > CacheTransactionSynchronization that will help us boost (1) even > further > by allowing us to execute all operations in parallel. And it's > good that > you've made the SPI more expressive with the intent; there'll be a > bunch > of TODOs in the 5.3 implementation to cover use cases that were not > handled in previous versions but now are obvious. > > Cheers > > Radim > > -- > Radim Vansa > > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Radim Vansa JBoss Performance Team From gbadner at redhat.com Tue Apr 3 20:59:59 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 3 Apr 2018 17:59:59 -0700 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 Message-ID: I've re-run the report to see what is still outstanding. Here's the link: https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By_FP0oj8DkHgiBE/edit?usp=sharing I'll share to the same people as the last report. Regards, Gail From guillaume.smet at gmail.com Wed Apr 4 10:49:19 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 4 Apr 2018 16:49:19 +0200 Subject: [hibernate-dev] [HV] Master is now 6.1, 6.0 is branched Message-ID: Hi, $SUBJECT says it all. I set up the CI jobs so everything should be fine on this front. Be careful to backport bug fixes to the 6.0 branch. -- Guillaume From guillaume.smet at gmail.com Wed Apr 4 12:43:47 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 4 Apr 2018 18:43:47 +0200 Subject: [hibernate-dev] [HV] Master is now 6.1, 6.0 is branched In-Reply-To: References: Message-ID: CI job hibernate-validator-6.0-jdk9 fixed. The MAVEN_OPTS were missing a specific add module option. Not sure how it didn't get copied when I copied the job from the master one though... On Wed, Apr 4, 2018 at 4:49 PM, Guillaume Smet wrote: > Hi, > > $SUBJECT says it all. > > I set up the CI jobs so everything should be fine on this front. > > Be careful to backport bug fixes to the 6.0 branch. > > -- > Guillaume > From steve at hibernate.org Wed Apr 4 18:53:13 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 04 Apr 2018 22:53:13 +0000 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: Are these in addition to the original documentation? How do we correlate things from this new doc that have already been addressed via the previous? On Tue, Apr 3, 2018 at 8:00 PM Gail Badner wrote: > I've re-run the report to see what is still outstanding. > > Here's the link: > > https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By_FP0oj8DkHgiBE/edit?usp=sharing > > I'll share to the same people as the last report. > > Regards, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Thu Apr 5 03:07:02 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 05 Apr 2018 07:07:02 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC Message-ID: Hello, With the Search 6 POC getting closer and closer to something we can merge, and thus more and more complex, we are starting to see quite a lot of TODOs piling up. I've been tracking most of them in a Google Doc so far, and it's fine for big architectural topics, but for small things it's clearly inadequate. What would you all think if we started to use the main Hibernate Search project to track the small TODOs we have in the Search 6 POC? We would probably have to add some JIRA Components that only make sense in Search 6 ("indexing", ...), but beyond that I don't think this would cause much trouble. The tickets would all be Tasks targeting version 6, and we could tag them with a new "POC-6.0" component if you think it's necessary. Examples of tasks would be: - Native sorts in the Lucene Sort DSL extension - Native predicates in the Lucene Predicate DSL extension - Rework the Lucene DSL implementations to fail fast when parameter conversion errors occur - Polish and test Stream indexing (add CompletableFuture returns in particular) - Decide wether to use absolute or relative object path in "nested" search predicates If this feels like too much garbage for the main bug tracker, we can create a separate JIRA project instead. But then this will add to the trouble we'll have to go through when merging (commits referring to tickets from another project). Sanne, all, WDYT? -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From sanne at hibernate.org Thu Apr 5 10:09:36 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 5 Apr 2018 15:09:36 +0100 Subject: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC In-Reply-To: References: Message-ID: +1 to create issues in "main" project JIRA Since JIRA is an issue tracker, some people frown upon its usage as planning tool. I also don't think it fits too well, especially when we go too much in detail with upfront planning, but it's not too bad. Preferrable to yet-another-tool. I don't think we need to "tag" them as POC-6, it's all the same project. Thanks, Sanne On 5 April 2018 at 08:07, Yoann Rodiere wrote: > Hello, > > With the Search 6 POC getting closer and closer to something we can merge, > and thus more and more complex, we are starting to see quite a lot of TODOs > piling up. > I've been tracking most of them in a Google Doc > > so far, and it's fine for big architectural topics, but for small things > it's clearly inadequate. > > What would you all think if we started to use the main Hibernate Search > project to track the small TODOs we have in the Search 6 POC? We would > probably have to add some JIRA Components that only make sense in Search 6 > ("indexing", ...), but beyond that I don't think this would cause much > trouble. > The tickets would all be Tasks targeting version 6, and we could tag them > with a new "POC-6.0" component if you think it's necessary. Examples of > tasks would be: > > - Native sorts in the Lucene Sort DSL extension > > - Native predicates in the Lucene Predicate DSL extension > > - Rework the Lucene DSL implementations to fail fast when parameter > conversion errors occur > > - Polish and test Stream indexing (add CompletableFuture returns in > particular) > - Decide wether to use absolute or relative object path in "nested" > search predicates > > If this feels like too much garbage for the main bug tracker, we can create > a separate JIRA project instead. But then this will add to the trouble > we'll have to go through when merging (commits referring to tickets from > another project). > > Sanne, all, WDYT? > -- > Yoann Rodiere > yoann at hibernate.org / yrodiere at redhat.com > Software Engineer > Hibernate NoORM team > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Thu Apr 5 16:48:47 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 5 Apr 2018 13:48:47 -0700 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: I basically re-ran the same report on the newer snapshots. Incompatibilities listed in the old report that were resolved do not appear in the new report. I also categorized the incompatibilities as discussed in comments in the second report (e.g., Failures Mitigated using Compatibility Transformer). I un-crossed-out the issues that were not resolved yet (e.g., by HHH-12424 ). I think the only unresolved comment was the one about JPA_METAMODEL_POPULATION, so I responded to it in the new report. On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole wrote: > Are these in addition to the original documentation? How do we correlate > things from this new doc that have already been addressed via the previous? > > On Tue, Apr 3, 2018 at 8:00 PM Gail Badner wrote: > >> I've re-run the report to see what is still outstanding. >> >> Here's the link: >> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By >> _FP0oj8DkHgiBE/edit?usp=sharing >> >> I'll share to the same people as the last report. >> >> Regards, >> Gail >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Thu Apr 5 16:55:40 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 05 Apr 2018 20:55:40 +0000 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: Awesome! I'm sure that took a lot of work - thank you On Thu, Apr 5, 2018 at 3:48 PM Gail Badner wrote: > I basically re-ran the same report on the newer snapshots. > Incompatibilities listed in the old report that were resolved do not appear > in the new report. > > I also categorized the incompatibilities as discussed in comments in the > second report (e.g., Failures Mitigated using Compatibility Transformer). > > I un-crossed-out the issues that were not resolved yet (e.g., by HHH-12424 > > ). > > I think the only unresolved comment was the one about > JPA_METAMODEL_POPULATION, so I responded to it in the new report. > > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole > wrote: > >> Are these in addition to the original documentation? How do we correlate >> things from this new doc that have already been addressed via the previous? >> >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner wrote: >> >>> I've re-run the report to see what is still outstanding. >>> >>> Here's the link: >>> >>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By_FP0oj8DkHgiBE/edit?usp=sharing >>> >>> I'll share to the same people as the last report. >>> >>> Regards, >>> Gail >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From sanne at hibernate.org Thu Apr 5 16:55:47 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 5 Apr 2018 21:55:47 +0100 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: This report is focusing on binary compatibility. Which is great, but we should also pay attention to some other significant incompatibilities such as HHH-12454. How do you prefer to track those, if at all? David mentioned that we're only *required* to provide binary compatibility, but we could of course be a bit better than the minimum required - when doable. On 5 April 2018 at 21:48, Gail Badner wrote: > I basically re-ran the same report on the newer snapshots. > Incompatibilities listed in the old report that were resolved do not appear > in the new report. > > I also categorized the incompatibilities as discussed in comments in the > second report (e.g., Failures Mitigated using Compatibility Transformer). > > I un-crossed-out the issues that were not resolved yet (e.g., by HHH-12424 > > ). > > I think the only unresolved comment was the one about > JPA_METAMODEL_POPULATION, so I responded to it in the new report. > > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole wrote: > >> Are these in addition to the original documentation? How do we correlate >> things from this new doc that have already been addressed via the previous? >> >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner wrote: >> >>> I've re-run the report to see what is still outstanding. >>> >>> Here's the link: >>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By >>> _FP0oj8DkHgiBE/edit?usp=sharing >>> >>> I'll share to the same people as the last report. >>> >>> Regards, >>> Gail >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Apr 5 17:03:16 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 05 Apr 2018 21:03:16 +0000 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: I am assuming that mean you behavioral compatibility (they act the same)... Well that's the point of tests. The real problem is that often there are not tests for a specific thing or someone changed the test expectations during development On Thu, Apr 5, 2018 at 3:56 PM Sanne Grinovero wrote: > This report is focusing on binary compatibility. Which is great, but > we should also pay attention to some other significant > incompatibilities such as HHH-12454. > > How do you prefer to track those, if at all? > > David mentioned that we're only *required* to provide binary > compatibility, but we could of course be a bit better than the minimum > required - when doable. > > > On 5 April 2018 at 21:48, Gail Badner wrote: > > I basically re-ran the same report on the newer snapshots. > > Incompatibilities listed in the old report that were resolved do not > appear > > in the new report. > > > > I also categorized the incompatibilities as discussed in comments in the > > second report (e.g., Failures Mitigated using Compatibility Transformer). > > > > I un-crossed-out the issues that were not resolved yet (e.g., by > HHH-12424 > > < > https://www.google.com/url?q=https://hibernate.atlassian.net/browse/HHH-12424&sa=D&ust=1522883266264000&usg=AFQjCNHpVLWh2bMWaaGQNl1ywkmjjQggSg > > > > ). > > > > I think the only unresolved comment was the one about > > JPA_METAMODEL_POPULATION, so I responded to it in the new report. > > > > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole > wrote: > > > >> Are these in addition to the original documentation? How do we > correlate > >> things from this new doc that have already been addressed via the > previous? > >> > >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner wrote: > >> > >>> I've re-run the report to see what is still outstanding. > >>> > >>> Here's the link: > >>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By > >>> _FP0oj8DkHgiBE/edit?usp=sharing > >>> > >>> I'll share to the same people as the last report. > >>> > >>> Regards, > >>> Gail > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Fri Apr 6 06:23:12 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 06 Apr 2018 10:23:12 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC In-Reply-To: References: Message-ID: Thanks, we will do that. I may add some markers to the tickets though (component, label, ...): I just thought we will need to list tickets that must be solved before we merge the POC into the main repository. On Thu, 5 Apr 2018 at 16:12 Sanne Grinovero wrote: > +1 to create issues in "main" project JIRA > > Since JIRA is an issue tracker, some people frown upon its usage as > planning tool. I also don't think it fits too well, especially when we > go too much in detail with upfront planning, but it's not too bad. > Preferrable to yet-another-tool. > > I don't think we need to "tag" them as POC-6, it's all the same project. > > Thanks, > Sanne > > > > > On 5 April 2018 at 08:07, Yoann Rodiere wrote: > > Hello, > > > > With the Search 6 POC getting closer and closer to something we can > merge, > > and thus more and more complex, we are starting to see quite a lot of > TODOs > > piling up. > > I've been tracking most of them in a Google Doc > > < > https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1 > > > > so far, and it's fine for big architectural topics, but for small things > > it's clearly inadequate. > > > > What would you all think if we started to use the main Hibernate Search > > project to track the small TODOs we have in the Search 6 POC? We would > > probably have to add some JIRA Components that only make sense in Search > 6 > > ("indexing", ...), but beyond that I don't think this would cause much > > trouble. > > The tickets would all be Tasks targeting version 6, and we could tag them > > with a new "POC-6.0" component if you think it's necessary. Examples of > > tasks would be: > > > > - Native sorts in the Lucene Sort DSL extension > > < > https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5 > > > > - Native predicates in the Lucene Predicate DSL extension > > < > https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5 > > > > - Rework the Lucene DSL implementations to fail fast when parameter > > conversion errors occur > > < > https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.xrk3mjaa7k9p > > > > - Polish and test Stream indexing (add CompletableFuture returns in > > particular) > > - Decide wether to use absolute or relative object path in "nested" > > search predicates > > > > If this feels like too much garbage for the main bug tracker, we can > create > > a separate JIRA project instead. But then this will add to the trouble > > we'll have to go through when merging (commits referring to tickets from > > another project). > > > > Sanne, all, WDYT? > > -- > > Yoann Rodiere > > yoann at hibernate.org / yrodiere at redhat.com > > Software Engineer > > Hibernate NoORM team > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From sanne at hibernate.org Fri Apr 6 09:51:21 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 6 Apr 2018 14:51:21 +0100 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: On 5 April 2018 at 22:03, Steve Ebersole wrote: > I am assuming that mean you behavioral compatibility (they act the same)... > > Well that's the point of tests. The real problem is that often there are > not tests for a specific thing or someone changed the test expectations > during development Agreed on the point of tests. But I'm wondering if we want to track existing behavioural incompatibilities we know of in a similar document / as an appendix of it / labels on JIRA. Granted the binary compatibility is the first and most important milestone, but I'd hope we could work also on some of the other ones such as HHH-12454. I'm not suggesting that we solve them all - but it would be good to collect a list of known compatibility issues to review once more as when we decided on breaking some thing we weren't evaluating problems in the light of continuous delivery requirements. Thanks, Sanne > > > On Thu, Apr 5, 2018 at 3:56 PM Sanne Grinovero wrote: >> >> This report is focusing on binary compatibility. Which is great, but >> we should also pay attention to some other significant >> incompatibilities such as HHH-12454. >> >> How do you prefer to track those, if at all? >> >> David mentioned that we're only *required* to provide binary >> compatibility, but we could of course be a bit better than the minimum >> required - when doable. >> >> >> On 5 April 2018 at 21:48, Gail Badner wrote: >> > I basically re-ran the same report on the newer snapshots. >> > Incompatibilities listed in the old report that were resolved do not >> > appear >> > in the new report. >> > >> > I also categorized the incompatibilities as discussed in comments in the >> > second report (e.g., Failures Mitigated using Compatibility >> > Transformer). >> > >> > I un-crossed-out the issues that were not resolved yet (e.g., by >> > HHH-12424 >> > >> > >> > ). >> > >> > I think the only unresolved comment was the one about >> > JPA_METAMODEL_POPULATION, so I responded to it in the new report. >> > >> > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole >> > wrote: >> > >> >> Are these in addition to the original documentation? How do we >> >> correlate >> >> things from this new doc that have already been addressed via the >> >> previous? >> >> >> >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner wrote: >> >> >> >>> I've re-run the report to see what is still outstanding. >> >>> >> >>> Here's the link: >> >>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By >> >>> _FP0oj8DkHgiBE/edit?usp=sharing >> >>> >> >>> I'll share to the same people as the last report. >> >>> >> >>> Regards, >> >>> Gail >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Apr 6 09:56:47 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 06 Apr 2018 13:56:47 +0000 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: That's called a migration guide :) And I agree, we should capture behavioral differences there too. On Fri, Apr 6, 2018 at 8:51 AM Sanne Grinovero wrote: > On 5 April 2018 at 22:03, Steve Ebersole wrote: > > I am assuming that mean you behavioral compatibility (they act the > same)... > > > > Well that's the point of tests. The real problem is that often there are > > not tests for a specific thing or someone changed the test expectations > > during development > > Agreed on the point of tests. But I'm wondering if we want to track > existing behavioural incompatibilities we know of in a similar > document / as an appendix of it / labels on JIRA. > > Granted the binary compatibility is the first and most important > milestone, but I'd hope we could work also on some of the other ones > such as HHH-12454. > > I'm not suggesting that we solve them all - but it would be good to > collect a list of known compatibility issues to review once more as > when we decided on breaking some thing we weren't evaluating problems > in the light of continuous delivery requirements. > > Thanks, > Sanne > > > > > > > On Thu, Apr 5, 2018 at 3:56 PM Sanne Grinovero > wrote: > >> > >> This report is focusing on binary compatibility. Which is great, but > >> we should also pay attention to some other significant > >> incompatibilities such as HHH-12454. > >> > >> How do you prefer to track those, if at all? > >> > >> David mentioned that we're only *required* to provide binary > >> compatibility, but we could of course be a bit better than the minimum > >> required - when doable. > >> > >> > >> On 5 April 2018 at 21:48, Gail Badner wrote: > >> > I basically re-ran the same report on the newer snapshots. > >> > Incompatibilities listed in the old report that were resolved do not > >> > appear > >> > in the new report. > >> > > >> > I also categorized the incompatibilities as discussed in comments in > the > >> > second report (e.g., Failures Mitigated using Compatibility > >> > Transformer). > >> > > >> > I un-crossed-out the issues that were not resolved yet (e.g., by > >> > HHH-12424 > >> > > >> > < > https://www.google.com/url?q=https://hibernate.atlassian.net/browse/HHH-12424&sa=D&ust=1522883266264000&usg=AFQjCNHpVLWh2bMWaaGQNl1ywkmjjQggSg > > > >> > ). > >> > > >> > I think the only unresolved comment was the one about > >> > JPA_METAMODEL_POPULATION, so I responded to it in the new report. > >> > > >> > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole > >> > wrote: > >> > > >> >> Are these in addition to the original documentation? How do we > >> >> correlate > >> >> things from this new doc that have already been addressed via the > >> >> previous? > >> >> > >> >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner > wrote: > >> >> > >> >>> I've re-run the report to see what is still outstanding. > >> >>> > >> >>> Here's the link: > >> >>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By > >> >>> _FP0oj8DkHgiBE/edit?usp=sharing > >> >>> > >> >>> I'll share to the same people as the last report. > >> >>> > >> >>> Regards, > >> >>> Gail > >> >>> _______________________________________________ > >> >>> hibernate-dev mailing list > >> >>> hibernate-dev at lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>> > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Fri Apr 6 10:44:55 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 6 Apr 2018 15:44:55 +0100 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: On 6 April 2018 at 14:56, Steve Ebersole wrote: > That's called a migration guide :) Good point :) > > And I agree, we should capture behavioral differences there too. > > On Fri, Apr 6, 2018 at 8:51 AM Sanne Grinovero wrote: >> >> On 5 April 2018 at 22:03, Steve Ebersole wrote: >> > I am assuming that mean you behavioral compatibility (they act the >> > same)... >> > >> > Well that's the point of tests. The real problem is that often there >> > are >> > not tests for a specific thing or someone changed the test expectations >> > during development >> >> Agreed on the point of tests. But I'm wondering if we want to track >> existing behavioural incompatibilities we know of in a similar >> document / as an appendix of it / labels on JIRA. >> >> Granted the binary compatibility is the first and most important >> milestone, but I'd hope we could work also on some of the other ones >> such as HHH-12454. >> >> I'm not suggesting that we solve them all - but it would be good to >> collect a list of known compatibility issues to review once more as >> when we decided on breaking some thing we weren't evaluating problems >> in the light of continuous delivery requirements. >> >> Thanks, >> Sanne >> >> > >> > >> > On Thu, Apr 5, 2018 at 3:56 PM Sanne Grinovero >> > wrote: >> >> >> >> This report is focusing on binary compatibility. Which is great, but >> >> we should also pay attention to some other significant >> >> incompatibilities such as HHH-12454. >> >> >> >> How do you prefer to track those, if at all? >> >> >> >> David mentioned that we're only *required* to provide binary >> >> compatibility, but we could of course be a bit better than the minimum >> >> required - when doable. >> >> >> >> >> >> On 5 April 2018 at 21:48, Gail Badner wrote: >> >> > I basically re-ran the same report on the newer snapshots. >> >> > Incompatibilities listed in the old report that were resolved do not >> >> > appear >> >> > in the new report. >> >> > >> >> > I also categorized the incompatibilities as discussed in comments in >> >> > the >> >> > second report (e.g., Failures Mitigated using Compatibility >> >> > Transformer). >> >> > >> >> > I un-crossed-out the issues that were not resolved yet (e.g., by >> >> > HHH-12424 >> >> > >> >> > >> >> > >> >> > ). >> >> > >> >> > I think the only unresolved comment was the one about >> >> > JPA_METAMODEL_POPULATION, so I responded to it in the new report. >> >> > >> >> > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole >> >> > wrote: >> >> > >> >> >> Are these in addition to the original documentation? How do we >> >> >> correlate >> >> >> things from this new doc that have already been addressed via the >> >> >> previous? >> >> >> >> >> >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner >> >> >> wrote: >> >> >> >> >> >>> I've re-run the report to see what is still outstanding. >> >> >>> >> >> >>> Here's the link: >> >> >>> https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By >> >> >>> _FP0oj8DkHgiBE/edit?usp=sharing >> >> >>> >> >> >>> I'll share to the same people as the last report. >> >> >>> >> >> >>> Regards, >> >> >>> Gail >> >> >>> _______________________________________________ >> >> >>> hibernate-dev mailing list >> >> >>> hibernate-dev at lists.jboss.org >> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >>> >> >> >> >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Fri Apr 6 10:49:14 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 6 Apr 2018 15:49:14 +0100 Subject: [hibernate-dev] HipChat / JIRA / Atlassian account(s) login Message-ID: Many of us reported problems with HipChat today / recently. It seems Atlassian has merged accounts of HipChat and various other services, like our JIRA. I would suggest to reset your password and consider that your new password will apply to all (most?) of your Atlassian accounts: I'm not sure what they did exactly, but after resetting my password on JIRA a couple of days back, now to login on HipChat I had to use that same password. HTH From daltodavide at gmail.com Sun Apr 8 17:13:21 2018 From: daltodavide at gmail.com (Davide D'Alto) Date: Sun, 8 Apr 2018 22:13:21 +0100 Subject: [hibernate-dev] Jenkins Updates Message-ID: Hi, I've run some updates on CI. Everything seems to work fine but keep that in mind if something weird happens. Cheers, Davide From fercoli at redhat.com Tue Apr 10 06:20:14 2018 From: fercoli at redhat.com (Fabio Massimo Ercoli) Date: Tue, 10 Apr 2018 12:20:14 +0200 Subject: [hibernate-dev] OpenShift Hibernate demo: Next Steps Message-ID: Hi, Andrea and me are starting the next sprint on OpenShift Hibernate demo. Based on the feedbacks we received, we have prepared this TODO list for the next steps: * Provide feedback on Infinispan OCP template * Extract template paramters and environment variables into secrets and config Maps. * Refactoring provisioning scripts based on Tristan suggestion: https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-services-dev/Makefile https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-services-dev/Jenkinsfile * Discuss Hibernate statup optimization on OCP. * Implement authentication and authorization. * Infinispan remote task to update the board (in future Stored procedure JPA) * Search / Query on messagges * Full text Search / Analytics on message content * Pipeline / DevOps ( Jenkins ) WDYT about it? Suggestions and ideas are more then wecolme. Cheers Fabio -- FABIO MASSIMO ERCOLI fabio.ercoli at redhat.com fabio at hibernate.org From sanne at hibernate.org Tue Apr 10 08:39:58 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 10 Apr 2018 13:39:58 +0100 Subject: [hibernate-dev] OpenShift Hibernate demo: Next Steps In-Reply-To: References: Message-ID: Hi Fabio, inline: On 10 April 2018 at 11:20, Fabio Massimo Ercoli wrote: > Hi, > > Andrea and me are starting the next sprint on OpenShift Hibernate demo. > Based on the feedbacks we received, we have prepared this TODO list for the > next steps: > > * Provide feedback on Infinispan OCP template +1 I started reporting some things: - https://github.com/infinispan/infinispan-openshift-templates/issues/17 - http://lists.jboss.org/pipermail/infinispan-dev/2018-April/018074.html Would be nice to see the cluster forming with no errors, ideally no warnings either. > > * Extract template paramters and environment variables into secrets and > config Maps. +1 > > * Refactoring provisioning scripts based on Tristan suggestion: > https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-services-dev/Makefile > https://github.com/jboss-container-images/datagrid-7-image/blob/datagrid-services-dev/Jenkinsfile +1 > * Discuss Hibernate statup optimization on OCP. We should improve the OGM modules so that we don't have to copy all the dependencies we don't need. For example today it takes some time as it's copying also all the Neo4J libraries; no big deal but this demo isn't using Neo4J, so it would be nice for people to be able to choose only the feature packs they need. > * Implement authentication and authorization. +1 > * Infinispan remote task to update the board (in future Stored procedure > JPA) +1 > * Search / Query on messagges You mean via Infinispan ICKLE in this case? > * Full text Search / Analytics on message content Using Hibernate Search + Elasticsearch > * Pipeline / DevOps ( Jenkins ) I'm not a big fan of this. I do like the pipelines and devops in principle and it's a nice feature of Openshift, but I believe there's no lack of demos on this topic while we should focus on Hibernate related improvements. We could add it as it might indeed look compellin in a full demo of the platform but let's keep this as very last priority. Adding one: * Let's keep the stack up to date to benefit from very latest improvements. I tested locally using Infinispan Server 9.2.1.Final, it looks like we could use this already even with the older OGM. I'd upgrade OGM to latest too but apparently we can keep these task items slightly separated. Thanks! Sanne > > WDYT about it? Suggestions and ideas are more then wecolme. > > Cheers > Fabio > > -- > > FABIO MASSIMO ERCOLI > > fabio.ercoli at redhat.com fabio at hibernate.org > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at hibernate.org Tue Apr 10 10:14:25 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 10 Apr 2018 16:14:25 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of our NoORM IRC meeting: 16:00 < jbott> Meeting ended Tue Apr 10 14:00:35 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:00 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-04-10-13.01.html 16:00 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-04-10-13.01.txt 16:00 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-04-10-13.01.log.html Cheers, -- Guillaume From yoann at hibernate.org Wed Apr 11 05:15:35 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 11 Apr 2018 09:15:35 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] Bug tracking for the Search 6 POC In-Reply-To: References: Message-ID: Hello, I created the JIRA tickets regarding all the little TODOs in the Search 6 POC. Sorry about the noise, but it had to be done :) I also created two new versions for the HSEARCH project on JIRA: - 6-before-POC-merge for tickets that should be addressed before merging the POC into the main Hibernate Search repository - 6-after-POC-merge for tickets that should be addressed after that merge I also moved the tickets from 5.x to 6 because they required API changes, and from 6 to 6-before-POC-merge because we actually already started the work on those tickets. To sum up: - Tickets we want to address before we merge the POC into the main Hibernate Search repository are there: https://hibernate.atlassian.net/projects/HSEARCH/versions/31657/tab/release-report-todo - Tickets we want to address after the merge are there: https://hibernate.atlassian.net/projects/HSEARCH/versions/31658/tab/release-report-todo - Tickets that we would like to address in 6.0, but haven't been scheduled yet are there: https://hibernate.atlassian.net/projects/HSEARCH/versions/19151/tab/release-report-todo - Tickets we definitely don't want to address in 6.0, but might address in 6.x: https://hibernate.atlassian.net/projects/HSEARCH/versions/28500/tab/release-report-todo - Big architectural topics requiring more discussion are still in the Google doc: https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.c855wnz3s57i On Fri, 6 Apr 2018 at 12:23 Yoann Rodiere wrote: > Thanks, we will do that. > I may add some markers to the tickets though (component, label, ...): I > just thought we will need to list tickets that must be solved before we > merge the POC into the main repository. > > On Thu, 5 Apr 2018 at 16:12 Sanne Grinovero wrote: > >> +1 to create issues in "main" project JIRA >> >> Since JIRA is an issue tracker, some people frown upon its usage as >> planning tool. I also don't think it fits too well, especially when we >> go too much in detail with upfront planning, but it's not too bad. >> Preferrable to yet-another-tool. >> >> I don't think we need to "tag" them as POC-6, it's all the same project. >> >> Thanks, >> Sanne >> >> >> >> >> On 5 April 2018 at 08:07, Yoann Rodiere wrote: >> > Hello, >> > >> > With the Search 6 POC getting closer and closer to something we can >> merge, >> > and thus more and more complex, we are starting to see quite a lot of >> TODOs >> > piling up. >> > I've been tracking most of them in a Google Doc >> > < >> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1 >> > >> > so far, and it's fine for big architectural topics, but for small things >> > it's clearly inadequate. >> > >> > What would you all think if we started to use the main Hibernate Search >> > project to track the small TODOs we have in the Search 6 POC? We would >> > probably have to add some JIRA Components that only make sense in >> Search 6 >> > ("indexing", ...), but beyond that I don't think this would cause much >> > trouble. >> > The tickets would all be Tasks targeting version 6, and we could tag >> them >> > with a new "POC-6.0" component if you think it's necessary. Examples of >> > tasks would be: >> > >> > - Native sorts in the Lucene Sort DSL extension >> > < >> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5 >> > >> > - Native predicates in the Lucene Predicate DSL extension >> > < >> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.1p57dh8ae6d5 >> > >> > - Rework the Lucene DSL implementations to fail fast when parameter >> > conversion errors occur >> > < >> https://docs.google.com/document/d/16PAa__LsxyLZcbW3q1MvgyIznh4ZnCYLupbNMXKMRds/edit?pli=1#heading=h.xrk3mjaa7k9p >> > >> > - Polish and test Stream indexing (add CompletableFuture returns in >> > particular) >> > - Decide wether to use absolute or relative object path in "nested" >> > search predicates >> > >> > If this feels like too much garbage for the main bug tracker, we can >> create >> > a separate JIRA project instead. But then this will add to the trouble >> > we'll have to go through when merging (commits referring to tickets from >> > another project). >> > >> > Sanne, all, WDYT? >> > -- >> > Yoann Rodiere >> > yoann at hibernate.org / yrodiere at redhat.com >> > Software Engineer >> > Hibernate NoORM team >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- > Yoann Rodiere > yoann at hibernate.org / yrodiere at redhat.com > Software Engineer > Hibernate NoORM team > -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From steve at hibernate.org Wed Apr 11 10:10:29 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 11 Apr 2018 14:10:29 +0000 Subject: [hibernate-dev] HipChat / JIRA / Atlassian account(s) login In-Reply-To: References: Message-ID: Ok, having this same problem again today. I think I've wasted enough time now trying to get Hip Chat to work on Fedora systems which they clearly don't care much about. I'll be on Hangouts and IRC if anyone needs me. On Fri, Apr 6, 2018 at 9:54 AM Sanne Grinovero wrote: > Many of us reported problems with HipChat today / recently. > > It seems Atlassian has merged accounts of HipChat and various other > services, like our > JIRA. > > I would suggest to reset your password and consider that your new > password will apply to all (most?) of your Atlassian accounts: > > I'm not sure what they did exactly, but after resetting my password on > JIRA a couple of days back, now to login on HipChat I had to use that > same password. > > HTH > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From rory.odonnell at oracle.com Thu Apr 12 06:03:34 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 12 Apr 2018 11:03:34 +0100 Subject: [hibernate-dev] JDK 11 Early Access build 8 available Message-ID: <674cb21a-0003-9509-9f86-5c52940b45be@oracle.com> Hi Sanne, **JDK 11 EA build 8, *****under both the GPL and Oracle EA licenses, is now available at **http://jdk.java.net/11**. ** * * Newly approved Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/8/jdk-11+8.html *Notable changes in JDK 11 EA builds since last email:* * Build 8: o If you have a library that uses the Selector API heavily then now would be a good time to test it out. [1] * Build 7 o The VM option "-XX:+AggressiveOpts" is deprecated in JDK 11 and will be removed in a future release. * Build 6: o JDK-8193033 : remove terminally deprecated sun.misc.Unsafe.defineClass. Users should use the public replacement `java.lang.invoke.MethodHandles.Lookup.defineClass` which was added in Java SE 9. [2] ** *SURVEY: The HotSpot Serviceability Agent (SA) *[3] * If you have used, or have (support) processes that utilize the Serviceability Agent or related APIs, then we would definitely appreciate if you would complete this survey: https://www.surveymonkey.com/r/CF3MYDL Regards, Rory [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-April/004964.html [2] https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/MethodHandles.Lookup.html#defineClass-byte:A- [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001052.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From steve at hibernate.org Thu Apr 12 08:45:51 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 12 Apr 2018 12:45:51 +0000 Subject: [hibernate-dev] HHH-8944 - ColumnTransformer handling is too aggressive in qualifying "column names" Message-ID: Anyone know of places where we document ColumnTransformer read-fragment handling as qualifying columns other than the column the transformer is attached to? E.g., consider: @Column( name="dob" ) @ColumnTransformer( read="SYSDATE - dob / 365", ... ) public int getAge() { ... } Currently, Hibernate will try to qualify both "SYSDATE" and "dob" with table alias. The simple fix is to simply limit the qualification to the column that the transformer is attached to ("dob"). Just want to make sure that we do not document anywhere that multiple column references will all be replaced. E.g. (contrived): @Column( name="dob" ) @ColumnTransformer( read="(SYSDATE - dob / 365) + offset", ... ) public int getAge() { ... } The question is whether both "dob" and "offset" columns will get qualified. Allowing this is much more involved, requiring that we somehow allow configuration of all the referenced columns that should be qualified (which has its own set of difficulties when it comes to multi-table structures). I propose the simple solution, unless there are any objections From steve at hibernate.org Thu Apr 12 09:55:58 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 12 Apr 2018 13:55:58 +0000 Subject: [hibernate-dev] HHH-8944 - ColumnTransformer handling is too aggressive in qualifying "column names" In-Reply-To: References: Message-ID: https://github.com/hibernate/hibernate-orm/pull/2237 On Thu, Apr 12, 2018 at 7:45 AM Steve Ebersole wrote: > Anyone know of places where we document ColumnTransformer read-fragment > handling as qualifying columns other than the column the transformer is > attached to? E.g., consider: > > @Column( name="dob" ) > @ColumnTransformer( read="SYSDATE - dob / 365", ... ) > public int getAge() { ... } > > Currently, Hibernate will try to qualify both "SYSDATE" and "dob" with > table alias. The simple fix is to simply limit the qualification to the > column that the transformer is attached to ("dob"). Just want to make sure > that we do not document anywhere that multiple column references will all > be replaced. E.g. (contrived): > > @Column( name="dob" ) > @ColumnTransformer( read="(SYSDATE - dob / 365) + offset", ... ) > public int getAge() { ... } > > The question is whether both "dob" and "offset" columns will get > qualified. Allowing this is much more involved, requiring that we somehow > allow configuration of all the referenced columns that should be qualified > (which has its own set of difficulties when it comes to multi-table > structures). > > I propose the simple solution, unless there are any objections > From yoann at hibernate.org Fri Apr 13 06:17:16 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Fri, 13 Apr 2018 10:17:16 +0000 Subject: [hibernate-dev] Hibernate Search 5.10.0.Beta2 Message-ID: Hi, We just published 5.10.0.Beta2, the second beta release for the 5.10 branch. This release mainly includes an upgrade to WildFly 12 for the JBoss modules, but it also adds a few bugfixes and improvements. Check out our blog for more information about this release: http://in.relation.to/2018/04/13/hibernate-search-5-10-0-Beta2/ -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From davide at hibernate.org Tue Apr 17 09:28:45 2018 From: davide at hibernate.org (Davide D'Alto) Date: Tue, 17 Apr 2018 14:28:45 +0100 Subject: [hibernate-dev] Hibernate OGM 5.4.0.Alpha1 release Message-ID: We?re happy to announce the release of Hibernate OGM 5.4.0.Alpha1. Hibernate OGM is now compatible with Hibernate ORM 5.3 (still a candidate release) and JPA 2.2. We support Infinipan 9.2 and JBoss modules are now available as WildFly feature packs. You can run server-side JavaScript on MongoDB or Java code in Infinispan Embedded as if they were stored procedures using the JPA approach. When using the Infinispan Remote dialect, it is now possible to configure new caches using the @CacheConfiguration annotation. You can find all the details in the blog post: http://in.relation.to/2018/04/17/hibernate-ogm-5-4-Alpha1-released/ Thanks, Davide From steve at hibernate.org Tue Apr 17 12:11:50 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 17 Apr 2018 16:11:50 +0000 Subject: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-pgsql #1038 In-Reply-To: <800389815.80.1523972100224.JavaMail.jenkins@ip-172-30-1-248.ec2.internal> References: <910876276.79.1523964886414.JavaMail.jenkins@ip-172-30-1-248.ec2.internal> <800389815.80.1523972100224.JavaMail.jenkins@ip-172-30-1-248.ec2.internal> Message-ID: I'm going to disable this build until we have a chance to figure out why it breaks constantly ---------- Forwarded message --------- From: Hibernate CI Date: Tue, Apr 17, 2018 at 8:35 AM Subject: Build failed in Jenkins: hibernate-orm-master-pgsql #1038 To: , , < rdrg.turini at gmail.com>, , , < chris at hibernate.org>, , , < dreborier at gmail.com>, See < http://ci.hibernate.org/job/hibernate-orm-master-pgsql/1038/display/redirect?page=changes > Changes: [rdrg.turini] HHH-12451 - Fixing JDBC and Java Type order for CurrencyType [Sanne Grinovero] HHH-12493 Further reduce allocations of ByteBuddy engines [Sanne Grinovero] Amend an out of date javadoc comment referring to CGLIB ------------------------------------------ [...truncated 128.65 KB...] org.hibernate.test.collection.delayedOperation.ListAddTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.delayedOperation.BagDelayedOperationTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.delayedOperation.SetDelayedOperationTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.delayedOperation.ListDelayedOperationTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.bag.PersistentBagTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.bag.PersistentBagContainsTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.bag.BagElementNullBasicTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.bag.MultipleBagFetchHqlTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.bag.BagDuplicatesTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.bag.MultipleBagFetchTest > testEntityWithMultipleJoinFetchedBags FAILED java.lang.OutOfMemoryError org.hibernate.test.collection.custom.basic.UserCollectionTypeAnnotationsVariantTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.custom.basic.UserCollectionTypeHbmVariantTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.custom.parameterized.ParameterizedUserCollectionTypeHbmVariantTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.custom.parameterized.ParameterizedUserCollectionTypeAnnotationsVariantTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.dereferenced.UnversionedCascadeDereferencedCollectionTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.dereferenced.UnversionedNoCascadeDereferencedCollectionTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.dereferenced.VersionedNoCascadeDereferencedCollectionTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.dereferenced.VersionedCascadeDereferencedCollectionTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.multisession.MultipleSessionCollectionWarningTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.multisession.MultipleSessionCollectionTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.list.ListIndexReferenceFromListElementTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.list.ListElementNullBasicTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.list.PersistentListTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.collection.backref.map.compkey.BackrefCompositeMapKeyTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.connections.BasicConnectionProviderTest > initializationError FAILED java.lang.OutOfMemoryError org.hibernate.test.connections.HibernateCreateBlobFailedCase > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaMigratorHaltOnErrorTest > testHaltOnError FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.MigrationTest > testIndexCreationViaSchemaUpdate FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.MigrationTest > testSameTableNameDifferentExplicitSchemas FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.MigrationTest > testSimpleColumnAddition FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.idbag.IdBagSequenceTest > testIdBagSequenceGeneratorIsCreated FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.QuotedTableNameSchemaUpdateTest > testSchemaUpdateWithQuotedTableName FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.IdentifierHelperTest > testAutoQuotingDisabled FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.inheritance.tableperclass.SchemaCreationTest > testUniqueConstraintIsCorrectlyGenerated FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.inheritance.ForeignKeyNameTest > testJoinedSubclassForeignKeyNameIsNotAutoGeneratedWhenProvided FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.inheritance.ForeignKeyNameTest > testSubclassForeignKeyNameIsNotAutoGeneratedWhenProvided FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.inheritance.hhh_x.InheritanceSchemaUpdateTest > testBidirectionalOneToManyReferencingRootEntity FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaUpdateWithViewsTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaUpdateTest > testSchemaUpdateAndValidation[0] FAILED java.lang.OutOfMemoryError java.lang.NullPointerException at SchemaUpdateTest.java:135 org.hibernate.test.schemaupdate.SchemaUpdateTest > testSchemaUpdateAndValidation[1] FAILED java.lang.OutOfMemoryError java.lang.NullPointerException at SchemaUpdateTest.java:135 org.hibernate.test.schemaupdate.SchemaMigrationTargetScriptCreationTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.index.ComponentIndexTest > testTheIndexIsGenerated FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.index.IndexesCreationTest > testTheIndexIsGenerated FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.TestFkUpdating > testUpdate FAILED java.lang.OutOfMemoryError java.lang.NullPointerException at TestFkUpdating.java:53 org.hibernate.test.schemaupdate.SchemaUpdateProceedOnErrorTest > testHaltOnError FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaExportTest > testBothType FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaExportTest > testCreateAndDrop FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaExportTest > testCreateAndDropOnlyType FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaExportTest > testGenerateDdlToFile FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaExportTest > testHibernateMappingSchemaPropertyIsNotIgnored FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.manytomany.ForeignKeyNameTest > testJoinedSubclassForeignKeyNameIsNotAutoGeneratedWhenProvided FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.TableCommentTest > classMethod FAILED org.hibernate.testing.junit4.CallbackException Caused by: java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaUpdateTableBackedSequenceTest > testCreateTableOnUpdate FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.CommentGenerationTest > testSchemaUpdateScriptGeneration FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest > testSchemaUpdateApplyDelimiterToGeneratedSQL FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.PostgreSQLMultipleSchemaSequenceTest > test FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.ConnectionsReleaseTest > testSchemaUpdateReleasesAllConnections FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.ConnectionsReleaseTest > testSchemaValidatorReleasesAllConnections FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.SchemaUpdateHaltOnErrorTest > testHaltOnError FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.foreignkeys.ForeignKeyDropTest > testForeignKeyDropIsCorrectlyGenerated FAILED java.lang.OutOfMemoryError org.hibernate.test.schemaupdate.foreignkeys.JoinedInheritanceForeignKeyTest > testForeignKeyHasCorrectName FAILED java.lang.OutOfMemoryError *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "pool-2501-thread-1" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "pool-234-thread-1" *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create name string at JPLISAgent.c line: 807 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create name string at JPLISAgent.c line: 807 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message can't create byte arrau at JPLISAgent.c line: 813 Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "pool-2514-thread-1" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "pool-2378-thread-1" Build timed out (after 120 minutes). Marking the build as failed. Build was aborted Recording test results Warning: user rdrg.turini at gmail.com has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway Warning: user sanne at hibernate.org has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway Warning: user jonathan.bregler at sap.com has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway Warning: user chris at hibernate.org has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway Warning: user github at s.traiectum.net has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway Warning: user arichir at altissia.com has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway Warning: user mihalcea.vlad at gmail.com has no permission to view hibernate-orm-master-pgsql #1038, but sending mail anyway From sanne at hibernate.org Tue Apr 17 13:09:51 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 17 Apr 2018 18:09:51 +0100 Subject: [hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-pgsql #1038 In-Reply-To: References: <910876276.79.1523964886414.JavaMail.jenkins@ip-172-30-1-248.ec2.internal> <800389815.80.1523972100224.JavaMail.jenkins@ip-172-30-1-248.ec2.internal> Message-ID: thanks Steve. I plan to co-work with Andrea to profile and inspect this together as it's a bit worrying. We were hoping to do that today but we had to reschedule; I still plan to at least know the reason this week. Sanne On 17 April 2018 at 17:11, Steve Ebersole wrote: > I'm going to disable this build until we have a chance to figure out why it > breaks constantly > > ---------- Forwarded message --------- > From: Hibernate CI > Date: Tue, Apr 17, 2018 at 8:35 AM > Subject: Build failed in Jenkins: hibernate-orm-master-pgsql #1038 > To: , , < > rdrg.turini at gmail.com>, , , < > chris at hibernate.org>, , , < > dreborier at gmail.com>, > > > See < > http://ci.hibernate.org/job/hibernate-orm-master-pgsql/1038/display/redirect?page=changes >> > > Changes: > > [rdrg.turini] HHH-12451 - Fixing JDBC and Java Type order for CurrencyType > > [Sanne Grinovero] HHH-12493 Further reduce allocations of ByteBuddy engines > > [Sanne Grinovero] Amend an out of date javadoc comment referring to CGLIB > > ------------------------------------------ > [...truncated 128.65 KB...] > > org.hibernate.test.collection.delayedOperation.ListAddTest > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.delayedOperation.BagDelayedOperationTest > > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.delayedOperation.SetDelayedOperationTest > > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.delayedOperation.ListDelayedOperationTest > > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.bag.PersistentBagTest > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.bag.PersistentBagContainsTest > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.bag.BagElementNullBasicTest > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.bag.MultipleBagFetchHqlTest > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.bag.BagDuplicatesTest > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.bag.MultipleBagFetchTest > > testEntityWithMultipleJoinFetchedBags FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.collection.custom.basic.UserCollectionTypeAnnotationsVariantTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.custom.basic.UserCollectionTypeHbmVariantTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.custom.parameterized.ParameterizedUserCollectionTypeHbmVariantTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.custom.parameterized.ParameterizedUserCollectionTypeAnnotationsVariantTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.dereferenced.UnversionedCascadeDereferencedCollectionTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.dereferenced.UnversionedNoCascadeDereferencedCollectionTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.dereferenced.VersionedNoCascadeDereferencedCollectionTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.dereferenced.VersionedCascadeDereferencedCollectionTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.multisession.MultipleSessionCollectionWarningTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.multisession.MultipleSessionCollectionTest > > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.list.ListIndexReferenceFromListElementTest > > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.list.ListElementNullBasicTest > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.list.PersistentListTest > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.collection.backref.map.compkey.BackrefCompositeMapKeyTest >> classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.connections.BasicConnectionProviderTest > > initializationError FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.connections.HibernateCreateBlobFailedCase > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaMigratorHaltOnErrorTest > > testHaltOnError FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.MigrationTest > > testIndexCreationViaSchemaUpdate FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.MigrationTest > > testSameTableNameDifferentExplicitSchemas FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.MigrationTest > testSimpleColumnAddition > FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.idbag.IdBagSequenceTest > > testIdBagSequenceGeneratorIsCreated FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.QuotedTableNameSchemaUpdateTest > > testSchemaUpdateWithQuotedTableName FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.IdentifierHelperTest > > testAutoQuotingDisabled FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.inheritance.tableperclass.SchemaCreationTest >> testUniqueConstraintIsCorrectlyGenerated FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.inheritance.ForeignKeyNameTest > > testJoinedSubclassForeignKeyNameIsNotAutoGeneratedWhenProvided FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.inheritance.ForeignKeyNameTest > > testSubclassForeignKeyNameIsNotAutoGeneratedWhenProvided FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.inheritance.hhh_x.InheritanceSchemaUpdateTest >> testBidirectionalOneToManyReferencingRootEntity FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaUpdateWithViewsTest > classMethod > FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaUpdateTest > > testSchemaUpdateAndValidation[0] FAILED > java.lang.OutOfMemoryError > java.lang.NullPointerException at SchemaUpdateTest.java:135 > > org.hibernate.test.schemaupdate.SchemaUpdateTest > > testSchemaUpdateAndValidation[1] FAILED > java.lang.OutOfMemoryError > java.lang.NullPointerException at SchemaUpdateTest.java:135 > > org.hibernate.test.schemaupdate.SchemaMigrationTargetScriptCreationTest > > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.index.ComponentIndexTest > > testTheIndexIsGenerated FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.index.IndexesCreationTest > > testTheIndexIsGenerated FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.TestFkUpdating > testUpdate FAILED > java.lang.OutOfMemoryError > java.lang.NullPointerException at TestFkUpdating.java:53 > > org.hibernate.test.schemaupdate.SchemaUpdateProceedOnErrorTest > > testHaltOnError FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaExportTest > testBothType FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaExportTest > testCreateAndDrop FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaExportTest > > testCreateAndDropOnlyType FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaExportTest > testGenerateDdlToFile > FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaExportTest > > testHibernateMappingSchemaPropertyIsNotIgnored FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.manytomany.ForeignKeyNameTest > > testJoinedSubclassForeignKeyNameIsNotAutoGeneratedWhenProvided FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.TableCommentTest > classMethod FAILED > org.hibernate.testing.junit4.CallbackException > Caused by: java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaUpdateTableBackedSequenceTest > > testCreateTableOnUpdate FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.CommentGenerationTest > > testSchemaUpdateScriptGeneration FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest > > testSchemaUpdateApplyDelimiterToGeneratedSQL FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.PostgreSQLMultipleSchemaSequenceTest > test > FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.ConnectionsReleaseTest > > testSchemaUpdateReleasesAllConnections FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.ConnectionsReleaseTest > > testSchemaValidatorReleasesAllConnections FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.SchemaUpdateHaltOnErrorTest > > testHaltOnError FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.foreignkeys.ForeignKeyDropTest > > testForeignKeyDropIsCorrectlyGenerated FAILED > java.lang.OutOfMemoryError > > org.hibernate.test.schemaupdate.foreignkeys.JoinedInheritanceForeignKeyTest >> testForeignKeyHasCorrectName FAILED > java.lang.OutOfMemoryError > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "pool-2501-thread-1" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "pool-234-thread-1" > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create name string at JPLISAgent.c line: 807 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create name string at JPLISAgent.c line: 807 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with > message can't create byte arrau at JPLISAgent.c line: 813 > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "pool-2514-thread-1" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "pool-2378-thread-1" > Build timed out (after 120 minutes). Marking the build as failed. > Build was aborted > Recording test results > Warning: user rdrg.turini at gmail.com has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > Warning: user sanne at hibernate.org has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > Warning: user jonathan.bregler at sap.com has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > Warning: user chris at hibernate.org has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > Warning: user github at s.traiectum.net has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > Warning: user arichir at altissia.com has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > Warning: user mihalcea.vlad at gmail.com has no permission to view > hibernate-orm-master-pgsql #1038, but sending mail anyway > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Wed Apr 18 11:21:21 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 18 Apr 2018 15:21:21 +0000 Subject: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3 In-Reply-To: References: Message-ID: I finished going through this second iteration. I started color each finding to better indicate its "status": - Blue = converted to a Jira - Red = things I do not think we want to change (migration guide) - Green = things that I considered "open items" - we should discuss further All have comments to a Jira, etc Let me know if anyone has further comments. P.S. Rather than keep an ever-expanding list of changes in the description of HHH-12424 I started making sub-tasks to track each piece. On Fri, Apr 6, 2018 at 9:45 AM Sanne Grinovero wrote: > On 6 April 2018 at 14:56, Steve Ebersole wrote: > > That's called a migration guide :) > > Good point :) > > > > > And I agree, we should capture behavioral differences there too. > > > > On Fri, Apr 6, 2018 at 8:51 AM Sanne Grinovero > wrote: > >> > >> On 5 April 2018 at 22:03, Steve Ebersole wrote: > >> > I am assuming that mean you behavioral compatibility (they act the > >> > same)... > >> > > >> > Well that's the point of tests. The real problem is that often there > >> > are > >> > not tests for a specific thing or someone changed the test > expectations > >> > during development > >> > >> Agreed on the point of tests. But I'm wondering if we want to track > >> existing behavioural incompatibilities we know of in a similar > >> document / as an appendix of it / labels on JIRA. > >> > >> Granted the binary compatibility is the first and most important > >> milestone, but I'd hope we could work also on some of the other ones > >> such as HHH-12454. > >> > >> I'm not suggesting that we solve them all - but it would be good to > >> collect a list of known compatibility issues to review once more as > >> when we decided on breaking some thing we weren't evaluating problems > >> in the light of continuous delivery requirements. > >> > >> Thanks, > >> Sanne > >> > >> > > >> > > >> > On Thu, Apr 5, 2018 at 3:56 PM Sanne Grinovero > >> > wrote: > >> >> > >> >> This report is focusing on binary compatibility. Which is great, but > >> >> we should also pay attention to some other significant > >> >> incompatibilities such as HHH-12454. > >> >> > >> >> How do you prefer to track those, if at all? > >> >> > >> >> David mentioned that we're only *required* to provide binary > >> >> compatibility, but we could of course be a bit better than the > minimum > >> >> required - when doable. > >> >> > >> >> > >> >> On 5 April 2018 at 21:48, Gail Badner wrote: > >> >> > I basically re-ran the same report on the newer snapshots. > >> >> > Incompatibilities listed in the old report that were resolved do > not > >> >> > appear > >> >> > in the new report. > >> >> > > >> >> > I also categorized the incompatibilities as discussed in comments > in > >> >> > the > >> >> > second report (e.g., Failures Mitigated using Compatibility > >> >> > Transformer). > >> >> > > >> >> > I un-crossed-out the issues that were not resolved yet (e.g., by > >> >> > HHH-12424 > >> >> > > >> >> > > >> >> > < > https://www.google.com/url?q=https://hibernate.atlassian.net/browse/HHH-12424&sa=D&ust=1522883266264000&usg=AFQjCNHpVLWh2bMWaaGQNl1ywkmjjQggSg > > > >> >> > ). > >> >> > > >> >> > I think the only unresolved comment was the one about > >> >> > JPA_METAMODEL_POPULATION, so I responded to it in the new report. > >> >> > > >> >> > On Wed, Apr 4, 2018 at 3:53 PM, Steve Ebersole < > steve at hibernate.org> > >> >> > wrote: > >> >> > > >> >> >> Are these in addition to the original documentation? How do we > >> >> >> correlate > >> >> >> things from this new doc that have already been addressed via the > >> >> >> previous? > >> >> >> > >> >> >> On Tue, Apr 3, 2018 at 8:00 PM Gail Badner > >> >> >> wrote: > >> >> >> > >> >> >>> I've re-run the report to see what is still outstanding. > >> >> >>> > >> >> >>> Here's the link: > >> >> >>> > https://docs.google.com/document/d/1ZjdVuNzYPjjmvVd7mDLw9zwy9c0By > >> >> >>> _FP0oj8DkHgiBE/edit?usp=sharing > >> >> >>> > >> >> >>> I'll share to the same people as the last report. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Gail > >> >> >>> _______________________________________________ > >> >> >>> hibernate-dev mailing list > >> >> >>> hibernate-dev at lists.jboss.org > >> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >> >>> > >> >> >> > >> >> > _______________________________________________ > >> >> > hibernate-dev mailing list > >> >> > hibernate-dev at lists.jboss.org > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Apr 19 16:10:23 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 19 Apr 2018 21:10:23 +0100 Subject: [hibernate-dev] Analyzing the ORM testsuite Message-ID: Hi all, I'm trying to analyze the memory usage of current master of Hibernate ORM; I started looking because of OOM errors on the PostgreSQL testsuite (as mentioned in another thread). So far I've seen that Mockito is allocating a "lot of stuff"; I might be able to improve some things in that area but it's a distraction from my goal as clearly we use Mockito even when not running the PostgreSQL backed tests and that seems to run fine. But it's polluting the data reports so making it hard (and slow!) to verify if there is a real issue. I could use some help to verify some tangential issues though; when running the testsuite locally it's taking much longer than what I've been used to see for the same testsuite some weeks ago, and I have some failures - regularly seeing the same failures. These are triggered by running a default build, on H2: > Task :hibernate-core:test org.hibernate.test.criteria.CriteriaLockingTest > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue FAILED org.junit.runners.model.TestTimedOutException org.hibernate.test.criteria.CriteriaLockingTest > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue FAILED java.lang.Exception org.hibernate.test.criteria.CriteriaLockingTest > org.hibernate.test.criteria.CriteriaLockingTest FAILED java.lang.Exception org.hibernate.test.locking.warning.LockNoneWarmingTest > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED java.lang.Exception 6307 tests completed, 4 failed, 327 skipped Yet the puzzling point: on ci.hibernate.org I don't see these failures happening, nor the testsuite time seems to have increased of any significant amount (it regularly completes in somewhere between 15 and 20 minutes). It takes me more than an hour to get this result on a machine which would normally complete the testsuite in 8 minutes, and I got the same 4 failures when re-running it a second time. Could other developers also please checkout master - specifically at commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if it works allright for you and if the build time is consistent with the usual times for your machine? I need to understand what might be different between my workstation and the CI server. I might even have some great improvements ready to reduce the testsuite time, but I'm not comfortable in committing them in this context. Thanks, Sanne From steve at hibernate.org Thu Apr 19 16:25:07 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 19 Apr 2018 20:25:07 +0000 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: Nothing off the top of my head. The build time is in normal range on my machine as of this morning (8 - 10 minutes). You mentioned a specific commit. Is that just when you noticed a change, or do you suspect something in that commit? I'm not at computer right now, but when I get back I will check out that commit and see if anything is strange locally. On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero wrote: > Hi all, > > I'm trying to analyze the memory usage of current master of Hibernate > ORM; I started looking because of OOM errors on the PostgreSQL > testsuite (as mentioned in another thread). > > So far I've seen that Mockito is allocating a "lot of stuff"; I might > be able to improve some things in that area but it's a distraction > from my goal as clearly we use Mockito even when not running the > PostgreSQL backed tests and that seems to run fine. But it's polluting > the data reports so making it hard (and slow!) to verify if there is a > real issue. > > I could use some help to verify some tangential issues though; when > running the testsuite locally it's taking much longer than what I've > been used to see for the same testsuite some weeks ago, and I have > some failures - regularly seeing the same failures. > > These are triggered by running a default build, on H2: > > > Task :hibernate-core:test > > org.hibernate.test.criteria.CriteriaLockingTest > > > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > FAILED > org.junit.runners.model.TestTimedOutException > > org.hibernate.test.criteria.CriteriaLockingTest > > > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > FAILED > java.lang.Exception > > org.hibernate.test.criteria.CriteriaLockingTest > > org.hibernate.test.criteria.CriteriaLockingTest FAILED > java.lang.Exception > > org.hibernate.test.locking.warning.LockNoneWarmingTest > > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED > java.lang.Exception > > 6307 tests completed, 4 failed, 327 skipped > > Yet the puzzling point: on ci.hibernate.org I don't see these failures > happening, nor the testsuite time seems to have increased of any > significant amount (it regularly completes in somewhere between 15 and > 20 minutes). It takes me more than an hour to get this result on a > machine which would normally complete the testsuite in 8 minutes, and > I got the same 4 failures when re-running it a second time. > > Could other developers also please checkout master - specifically at > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if > it works allright for you and if the build time is consistent with the > usual times for your machine? I need to understand what might be > different between my workstation and the CI server. > > I might even have some great improvements ready to reduce the > testsuite time, but I'm not comfortable in committing them in this > context. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From chris at hibernate.org Thu Apr 19 16:47:23 2018 From: chris at hibernate.org (Chris Cranford) Date: Thu, 19 Apr 2018 16:47:23 -0400 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: Sanne - Are you running the build task or are you executing other more specific tasks and noticing the slowness? On 04/19/2018 04:25 PM, Steve Ebersole wrote: > Nothing off the top of my head. The build time is in normal range on my > machine as of this morning (8 - 10 minutes). > > You mentioned a specific commit. Is that just when you noticed a change, > or do you suspect something in that commit? > > I'm not at computer right now, but when I get back I will check out that > commit and see if anything is strange locally. > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero wrote: > >> Hi all, >> >> I'm trying to analyze the memory usage of current master of Hibernate >> ORM; I started looking because of OOM errors on the PostgreSQL >> testsuite (as mentioned in another thread). >> >> So far I've seen that Mockito is allocating a "lot of stuff"; I might >> be able to improve some things in that area but it's a distraction >> from my goal as clearly we use Mockito even when not running the >> PostgreSQL backed tests and that seems to run fine. But it's polluting >> the data reports so making it hard (and slow!) to verify if there is a >> real issue. >> >> I could use some help to verify some tangential issues though; when >> running the testsuite locally it's taking much longer than what I've >> been used to see for the same testsuite some weeks ago, and I have >> some failures - regularly seeing the same failures. >> >> These are triggered by running a default build, on H2: >> >>> Task :hibernate-core:test >> org.hibernate.test.criteria.CriteriaLockingTest > >> >> testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> FAILED >> org.junit.runners.model.TestTimedOutException >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> >> testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> FAILED >> java.lang.Exception >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> org.hibernate.test.criteria.CriteriaLockingTest FAILED >> java.lang.Exception >> >> org.hibernate.test.locking.warning.LockNoneWarmingTest > >> org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED >> java.lang.Exception >> >> 6307 tests completed, 4 failed, 327 skipped >> >> Yet the puzzling point: on ci.hibernate.org I don't see these failures >> happening, nor the testsuite time seems to have increased of any >> significant amount (it regularly completes in somewhere between 15 and >> 20 minutes). It takes me more than an hour to get this result on a >> machine which would normally complete the testsuite in 8 minutes, and >> I got the same 4 failures when re-running it a second time. >> >> Could other developers also please checkout master - specifically at >> commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if >> it works allright for you and if the build time is consistent with the >> usual times for your machine? I need to understand what might be >> different between my workstation and the CI server. >> >> I might even have some great improvements ready to reduce the >> testsuite time, but I'm not comfortable in committing them in this >> context. >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Apr 19 17:17:40 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 19 Apr 2018 22:17:40 +0100 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: On 19 April 2018 at 21:25, Steve Ebersole wrote: > Nothing off the top of my head. The build time is in normal range on my > machine as of this morning (8 - 10 minutes). Great > You mentioned a specific commit. Is that just when you noticed a change, or > do you suspect something in that commit? Not suspecting anything yet, I just mentioned it so that people could try reproduce in the most similar context. > I'm not at computer right now, but when I get back I will check out that > commit and see if anything is strange locally. Don't worry on the specific commit, it's very useful to know it works "in normal ranges" for others. Thanks, Sanne > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero wrote: >> >> Hi all, >> >> I'm trying to analyze the memory usage of current master of Hibernate >> ORM; I started looking because of OOM errors on the PostgreSQL >> testsuite (as mentioned in another thread). >> >> So far I've seen that Mockito is allocating a "lot of stuff"; I might >> be able to improve some things in that area but it's a distraction >> from my goal as clearly we use Mockito even when not running the >> PostgreSQL backed tests and that seems to run fine. But it's polluting >> the data reports so making it hard (and slow!) to verify if there is a >> real issue. >> >> I could use some help to verify some tangential issues though; when >> running the testsuite locally it's taking much longer than what I've >> been used to see for the same testsuite some weeks ago, and I have >> some failures - regularly seeing the same failures. >> >> These are triggered by running a default build, on H2: >> >> > Task :hibernate-core:test >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> >> testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> FAILED >> org.junit.runners.model.TestTimedOutException >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> >> testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> FAILED >> java.lang.Exception >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> org.hibernate.test.criteria.CriteriaLockingTest FAILED >> java.lang.Exception >> >> org.hibernate.test.locking.warning.LockNoneWarmingTest > >> org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED >> java.lang.Exception >> >> 6307 tests completed, 4 failed, 327 skipped >> >> Yet the puzzling point: on ci.hibernate.org I don't see these failures >> happening, nor the testsuite time seems to have increased of any >> significant amount (it regularly completes in somewhere between 15 and >> 20 minutes). It takes me more than an hour to get this result on a >> machine which would normally complete the testsuite in 8 minutes, and >> I got the same 4 failures when re-running it a second time. >> >> Could other developers also please checkout master - specifically at >> commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if >> it works allright for you and if the build time is consistent with the >> usual times for your machine? I need to understand what might be >> different between my workstation and the CI server. >> >> I might even have some great improvements ready to reduce the >> testsuite time, but I'm not comfortable in committing them in this >> context. >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Apr 19 17:20:24 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 19 Apr 2018 22:20:24 +0100 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: On 19 April 2018 at 21:47, Chris Cranford wrote: > Sanne - > > Are you running the build task or are you executing other more specific > tasks and noticing the slowness? Just running "gradle clean build" from the root. I had the same results with OpenJDK 8 and 9, twice. Getting exactly the same failures as before. Thanks! > > On 04/19/2018 04:25 PM, Steve Ebersole wrote: > > Nothing off the top of my head. The build time is in normal range on my > machine as of this morning (8 - 10 minutes). > > You mentioned a specific commit. Is that just when you noticed a change, > or do you suspect something in that commit? > > I'm not at computer right now, but when I get back I will check out that > commit and see if anything is strange locally. > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero wrote: > > Hi all, > > I'm trying to analyze the memory usage of current master of Hibernate > ORM; I started looking because of OOM errors on the PostgreSQL > testsuite (as mentioned in another thread). > > So far I've seen that Mockito is allocating a "lot of stuff"; I might > be able to improve some things in that area but it's a distraction > from my goal as clearly we use Mockito even when not running the > PostgreSQL backed tests and that seems to run fine. But it's polluting > the data reports so making it hard (and slow!) to verify if there is a > real issue. > > I could use some help to verify some tangential issues though; when > running the testsuite locally it's taking much longer than what I've > been used to see for the same testsuite some weeks ago, and I have > some failures - regularly seeing the same failures. > > These are triggered by running a default build, on H2: > > Task :hibernate-core:test > > org.hibernate.test.criteria.CriteriaLockingTest > > > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > FAILED > org.junit.runners.model.TestTimedOutException > > org.hibernate.test.criteria.CriteriaLockingTest > > > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > FAILED > java.lang.Exception > > org.hibernate.test.criteria.CriteriaLockingTest > > org.hibernate.test.criteria.CriteriaLockingTest FAILED > java.lang.Exception > > org.hibernate.test.locking.warning.LockNoneWarmingTest > > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED > java.lang.Exception > > 6307 tests completed, 4 failed, 327 skipped > > Yet the puzzling point: on ci.hibernate.org I don't see these failures > happening, nor the testsuite time seems to have increased of any > significant amount (it regularly completes in somewhere between 15 and > 20 minutes). It takes me more than an hour to get this result on a > machine which would normally complete the testsuite in 8 minutes, and > I got the same 4 failures when re-running it a second time. > > Could other developers also please checkout master - specifically at > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if > it works allright for you and if the build time is consistent with the > usual times for your machine? I need to understand what might be > different between my workstation and the CI server. > > I might even have some great improvements ready to reduce the > testsuite time, but I'm not comfortable in committing them in this > context. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From chris at hibernate.org Thu Apr 19 17:50:35 2018 From: chris at hibernate.org (Chris Cranford) Date: Thu, 19 Apr 2018 17:50:35 -0400 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: <05f96743-4663-7279-ae5f-ee39cc2b42ed@hibernate.org> The entire build process under OpenJDK 8 here: BUILD SUCCESSFUL in 47m 26s 251 actionable tasks: 233 executed, 18 up-to-date The only thing I noticed was that while executing the hibernate-core tests, the memory consumption seemed quite high toward the end of the test suite, particularly ~3.5GB memory consumed just to run the hibernate-core tests alone and that FindBugs complained about some magic numbers on some zip files while inspecting hibernate-osgi.? Any idea if any substantial amount of that memory consumption related to the test framework tracking the output/errors of those executed tests?? On 04/19/2018 05:20 PM, Sanne Grinovero wrote: > On 19 April 2018 at 21:47, Chris Cranford wrote: >> Sanne - >> >> Are you running the build task or are you executing other more specific >> tasks and noticing the slowness? > Just running "gradle clean build" from the root. I had the same > results with OpenJDK 8 and 9, twice. Getting exactly the same failures > as before. > > Thanks! > >> On 04/19/2018 04:25 PM, Steve Ebersole wrote: >> >> Nothing off the top of my head. The build time is in normal range on my >> machine as of this morning (8 - 10 minutes). >> >> You mentioned a specific commit. Is that just when you noticed a change, >> or do you suspect something in that commit? >> >> I'm not at computer right now, but when I get back I will check out that >> commit and see if anything is strange locally. >> >> >> >> On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero wrote: >> >> Hi all, >> >> I'm trying to analyze the memory usage of current master of Hibernate >> ORM; I started looking because of OOM errors on the PostgreSQL >> testsuite (as mentioned in another thread). >> >> So far I've seen that Mockito is allocating a "lot of stuff"; I might >> be able to improve some things in that area but it's a distraction >> from my goal as clearly we use Mockito even when not running the >> PostgreSQL backed tests and that seems to run fine. But it's polluting >> the data reports so making it hard (and slow!) to verify if there is a >> real issue. >> >> I could use some help to verify some tangential issues though; when >> running the testsuite locally it's taking much longer than what I've >> been used to see for the same testsuite some weeks ago, and I have >> some failures - regularly seeing the same failures. >> >> These are triggered by running a default build, on H2: >> >> Task :hibernate-core:test >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> >> testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> FAILED >> org.junit.runners.model.TestTimedOutException >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> >> testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> FAILED >> java.lang.Exception >> >> org.hibernate.test.criteria.CriteriaLockingTest > >> org.hibernate.test.criteria.CriteriaLockingTest FAILED >> java.lang.Exception >> >> org.hibernate.test.locking.warning.LockNoneWarmingTest > >> org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED >> java.lang.Exception >> >> 6307 tests completed, 4 failed, 327 skipped >> >> Yet the puzzling point: on ci.hibernate.org I don't see these failures >> happening, nor the testsuite time seems to have increased of any >> significant amount (it regularly completes in somewhere between 15 and >> 20 minutes). It takes me more than an hour to get this result on a >> machine which would normally complete the testsuite in 8 minutes, and >> I got the same 4 failures when re-running it a second time. >> >> Could other developers also please checkout master - specifically at >> commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if >> it works allright for you and if the build time is consistent with the >> usual times for your machine? I need to understand what might be >> different between my workstation and the CI server. >> >> I might even have some great improvements ready to reduce the >> testsuite time, but I'm not comfortable in committing them in this >> context. >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Thu Apr 19 18:00:19 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 19 Apr 2018 15:00:19 -0700 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: I'm not seeing anything unusual. I usually run `./gradlew clean test`. On Thu, Apr 19, 2018 at 2:20 PM, Sanne Grinovero wrote: > On 19 April 2018 at 21:47, Chris Cranford wrote: > > Sanne - > > > > Are you running the build task or are you executing other more specific > > tasks and noticing the slowness? > > Just running "gradle clean build" from the root. I had the same > results with OpenJDK 8 and 9, twice. Getting exactly the same failures > as before. > > Thanks! > > > > > On 04/19/2018 04:25 PM, Steve Ebersole wrote: > > > > Nothing off the top of my head. The build time is in normal range on my > > machine as of this morning (8 - 10 minutes). > > > > You mentioned a specific commit. Is that just when you noticed a change, > > or do you suspect something in that commit? > > > > I'm not at computer right now, but when I get back I will check out that > > commit and see if anything is strange locally. > > > > > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero > wrote: > > > > Hi all, > > > > I'm trying to analyze the memory usage of current master of Hibernate > > ORM; I started looking because of OOM errors on the PostgreSQL > > testsuite (as mentioned in another thread). > > > > So far I've seen that Mockito is allocating a "lot of stuff"; I might > > be able to improve some things in that area but it's a distraction > > from my goal as clearly we use Mockito even when not running the > > PostgreSQL backed tests and that seems to run fine. But it's polluting > > the data reports so making it hard (and slow!) to verify if there is a > > real issue. > > > > I could use some help to verify some tangential issues though; when > > running the testsuite locally it's taking much longer than what I've > > been used to see for the same testsuite some weeks ago, and I have > > some failures - regularly seeing the same failures. > > > > These are triggered by running a default build, on H2: > > > > Task :hibernate-core:test > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialec > tUseFollowOnLockingIsTrue > > FAILED > > org.junit.runners.model.TestTimedOutException > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFoll > owOnLockingIsTrue > > FAILED > > java.lang.Exception > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > org.hibernate.test.criteria.CriteriaLockingTest FAILED > > java.lang.Exception > > > > org.hibernate.test.locking.warning.LockNoneWarmingTest > > > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED > > java.lang.Exception > > > > 6307 tests completed, 4 failed, 327 skipped > > > > Yet the puzzling point: on ci.hibernate.org I don't see these failures > > happening, nor the testsuite time seems to have increased of any > > significant amount (it regularly completes in somewhere between 15 and > > 20 minutes). It takes me more than an hour to get this result on a > > machine which would normally complete the testsuite in 8 minutes, and > > I got the same 4 failures when re-running it a second time. > > > > Could other developers also please checkout master - specifically at > > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if > > it works allright for you and if the build time is consistent with the > > usual times for your machine? I need to understand what might be > > different between my workstation and the CI server. > > > > I might even have some great improvements ready to reduce the > > testsuite time, but I'm not comfortable in committing them in this > > context. > > > > Thanks, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Apr 19 18:21:24 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 19 Apr 2018 22:21:24 +0000 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: Message-ID: I may be wrong, but I believe that the `build` task runs checkstyle, etc. Findbugs especially takes a ton of time. Have you tried just test? I have noticed that it seems like test causes javadoc to run as well, which I had intended to look at. But that seems not relevant to what you see On Thu, Apr 19, 2018, 5:01 PM Gail Badner wrote: > I'm not seeing anything unusual. I usually run `./gradlew clean test`. > > On Thu, Apr 19, 2018 at 2:20 PM, Sanne Grinovero > wrote: > > > On 19 April 2018 at 21:47, Chris Cranford wrote: > > > Sanne - > > > > > > Are you running the build task or are you executing other more specific > > > tasks and noticing the slowness? > > > > Just running "gradle clean build" from the root. I had the same > > results with OpenJDK 8 and 9, twice. Getting exactly the same failures > > as before. > > > > Thanks! > > > > > > > > On 04/19/2018 04:25 PM, Steve Ebersole wrote: > > > > > > Nothing off the top of my head. The build time is in normal range on > my > > > machine as of this morning (8 - 10 minutes). > > > > > > You mentioned a specific commit. Is that just when you noticed a > change, > > > or do you suspect something in that commit? > > > > > > I'm not at computer right now, but when I get back I will check out > that > > > commit and see if anything is strange locally. > > > > > > > > > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero > > wrote: > > > > > > Hi all, > > > > > > I'm trying to analyze the memory usage of current master of Hibernate > > > ORM; I started looking because of OOM errors on the PostgreSQL > > > testsuite (as mentioned in another thread). > > > > > > So far I've seen that Mockito is allocating a "lot of stuff"; I might > > > be able to improve some things in that area but it's a distraction > > > from my goal as clearly we use Mockito even when not running the > > > PostgreSQL backed tests and that seems to run fine. But it's polluting > > > the data reports so making it hard (and slow!) to verify if there is a > > > real issue. > > > > > > I could use some help to verify some tangential issues though; when > > > running the testsuite locally it's taking much longer than what I've > > > been used to see for the same testsuite some weeks ago, and I have > > > some failures - regularly seeing the same failures. > > > > > > These are triggered by running a default build, on H2: > > > > > > Task :hibernate-core:test > > > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > > > > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialec > > tUseFollowOnLockingIsTrue > > > FAILED > > > org.junit.runners.model.TestTimedOutException > > > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > > > > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFoll > > owOnLockingIsTrue > > > FAILED > > > java.lang.Exception > > > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > org.hibernate.test.criteria.CriteriaLockingTest FAILED > > > java.lang.Exception > > > > > > org.hibernate.test.locking.warning.LockNoneWarmingTest > > > > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED > > > java.lang.Exception > > > > > > 6307 tests completed, 4 failed, 327 skipped > > > > > > Yet the puzzling point: on ci.hibernate.org I don't see these failures > > > happening, nor the testsuite time seems to have increased of any > > > significant amount (it regularly completes in somewhere between 15 and > > > 20 minutes). It takes me more than an hour to get this result on a > > > machine which would normally complete the testsuite in 8 minutes, and > > > I got the same 4 failures when re-running it a second time. > > > > > > Could other developers also please checkout master - specifically at > > > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if > > > it works allright for you and if the build time is consistent with the > > > usual times for your machine? I need to understand what might be > > > different between my workstation and the CI server. > > > > > > I might even have some great improvements ready to reduce the > > > testsuite time, but I'm not comfortable in committing them in this > > > context. > > > > > > Thanks, > > > Sanne > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Apr 19 18:32:04 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 19 Apr 2018 23:32:04 +0100 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: <05f96743-4663-7279-ae5f-ee39cc2b42ed@hibernate.org> References: <05f96743-4663-7279-ae5f-ee39cc2b42ed@hibernate.org> Message-ID: On 19 April 2018 at 22:50, Chris Cranford wrote: > The entire build process under OpenJDK 8 here: > > BUILD SUCCESSFUL in 47m 26s > 251 actionable tasks: 233 executed, 18 up-to-date > > The only thing I noticed was that while executing the hibernate-core tests, > the memory consumption seemed quite high toward the end of the test suite, > particularly ~3.5GB memory consumed just to run the hibernate-core tests > alone and that FindBugs complained about some magic numbers on some zip > files while inspecting hibernate-osgi. > > Any idea if any substantial amount of that memory consumption related to the > test framework tracking the output/errors of those executed tests? I guess that confirms there's something specific to my environment. That's a great hint to have, thanks! Regarding the memory, yes I'm seeing the same. >90% of that is Mockito, I'm exploring some ideas to reduce its memory usage; I have some working experiments but I'm not happy with them: they make maintenance of tests error prone so tomorrow I'll try some alternatives. > > On 04/19/2018 05:20 PM, Sanne Grinovero wrote: > > On 19 April 2018 at 21:47, Chris Cranford wrote: > > Sanne - > > Are you running the build task or are you executing other more specific > tasks and noticing the slowness? > > Just running "gradle clean build" from the root. I had the same > results with OpenJDK 8 and 9, twice. Getting exactly the same failures > as before. > > Thanks! > > On 04/19/2018 04:25 PM, Steve Ebersole wrote: > > Nothing off the top of my head. The build time is in normal range on my > machine as of this morning (8 - 10 minutes). > > You mentioned a specific commit. Is that just when you noticed a change, > or do you suspect something in that commit? > > I'm not at computer right now, but when I get back I will check out that > commit and see if anything is strange locally. > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero wrote: > > Hi all, > > I'm trying to analyze the memory usage of current master of Hibernate > ORM; I started looking because of OOM errors on the PostgreSQL > testsuite (as mentioned in another thread). > > So far I've seen that Mockito is allocating a "lot of stuff"; I might > be able to improve some things in that area but it's a distraction > from my goal as clearly we use Mockito even when not running the > PostgreSQL backed tests and that seems to run fine. But it's polluting > the data reports so making it hard (and slow!) to verify if there is a > real issue. > > I could use some help to verify some tangential issues though; when > running the testsuite locally it's taking much longer than what I've > been used to see for the same testsuite some weeks ago, and I have > some failures - regularly seeing the same failures. > > These are triggered by running a default build, on H2: > > Task :hibernate-core:test > > org.hibernate.test.criteria.CriteriaLockingTest > > > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > FAILED > org.junit.runners.model.TestTimedOutException > > org.hibernate.test.criteria.CriteriaLockingTest > > > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > FAILED > java.lang.Exception > > org.hibernate.test.criteria.CriteriaLockingTest > > org.hibernate.test.criteria.CriteriaLockingTest FAILED > java.lang.Exception > > org.hibernate.test.locking.warning.LockNoneWarmingTest > > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED > java.lang.Exception > > 6307 tests completed, 4 failed, 327 skipped > > Yet the puzzling point: on ci.hibernate.org I don't see these failures > happening, nor the testsuite time seems to have increased of any > significant amount (it regularly completes in somewhere between 15 and > 20 minutes). It takes me more than an hour to get this result on a > machine which would normally complete the testsuite in 8 minutes, and > I got the same 4 failures when re-running it a second time. > > Could other developers also please checkout master - specifically at > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if > it works allright for you and if the build time is consistent with the > usual times for your machine? I need to understand what might be > different between my workstation and the CI server. > > I might even have some great improvements ready to reduce the > testsuite time, but I'm not comfortable in committing them in this > context. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Thu Apr 19 20:14:02 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 20 Apr 2018 00:14:02 +0000 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: <05f96743-4663-7279-ae5f-ee39cc2b42ed@hibernate.org> Message-ID: I checked - `build` does in fact pull in a bunch of tasks that you do not care about (checkstyle, findbugs, etc). The build I just ran did take longer than I have been seeing - it took 16 minutes, but that's not the magnitude you see. I mentioned performing test caused javadoc to be generated. I found the culprit for that - hibernate-orm-modules. Any time tests use hibernate-orm-modules, hibernate-orm-modules triggers a full build and publish of the project's artifacts (jar, source jar, javadoc jar). This accounts for at least some of the additional time. I think using build rather than test probably accounts for the rest On Thu, Apr 19, 2018 at 5:35 PM Sanne Grinovero wrote: > On 19 April 2018 at 22:50, Chris Cranford wrote: > > The entire build process under OpenJDK 8 here: > > > > BUILD SUCCESSFUL in 47m 26s > > 251 actionable tasks: 233 executed, 18 up-to-date > > > > The only thing I noticed was that while executing the hibernate-core > tests, > > the memory consumption seemed quite high toward the end of the test > suite, > > particularly ~3.5GB memory consumed just to run the hibernate-core tests > > alone and that FindBugs complained about some magic numbers on some zip > > files while inspecting hibernate-osgi. > > > > Any idea if any substantial amount of that memory consumption related to > the > > test framework tracking the output/errors of those executed tests? > > I guess that confirms there's something specific to my environment. > That's a great hint to have, thanks! > > Regarding the memory, yes I'm seeing the same. >90% of that is > Mockito, I'm exploring some ideas to reduce its memory usage; I have > some working experiments but I'm not happy with them: they make > maintenance of tests error prone so tomorrow I'll try some > alternatives. > > > > > > On 04/19/2018 05:20 PM, Sanne Grinovero wrote: > > > > On 19 April 2018 at 21:47, Chris Cranford wrote: > > > > Sanne - > > > > Are you running the build task or are you executing other more specific > > tasks and noticing the slowness? > > > > Just running "gradle clean build" from the root. I had the same > > results with OpenJDK 8 and 9, twice. Getting exactly the same failures > > as before. > > > > Thanks! > > > > On 04/19/2018 04:25 PM, Steve Ebersole wrote: > > > > Nothing off the top of my head. The build time is in normal range on my > > machine as of this morning (8 - 10 minutes). > > > > You mentioned a specific commit. Is that just when you noticed a change, > > or do you suspect something in that commit? > > > > I'm not at computer right now, but when I get back I will check out that > > commit and see if anything is strange locally. > > > > > > > > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero > wrote: > > > > Hi all, > > > > I'm trying to analyze the memory usage of current master of Hibernate > > ORM; I started looking because of OOM errors on the PostgreSQL > > testsuite (as mentioned in another thread). > > > > So far I've seen that Mockito is allocating a "lot of stuff"; I might > > be able to improve some things in that area but it's a distraction > > from my goal as clearly we use Mockito even when not running the > > PostgreSQL backed tests and that seems to run fine. But it's polluting > > the data reports so making it hard (and slow!) to verify if there is a > > real issue. > > > > I could use some help to verify some tangential issues though; when > > running the testsuite locally it's taking much longer than what I've > > been used to see for the same testsuite some weeks ago, and I have > > some failures - regularly seeing the same failures. > > > > These are triggered by running a default build, on H2: > > > > Task :hibernate-core:test > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > > > testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > > FAILED > > org.junit.runners.model.TestTimedOutException > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > > > > testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue > > FAILED > > java.lang.Exception > > > > org.hibernate.test.criteria.CriteriaLockingTest > > > org.hibernate.test.criteria.CriteriaLockingTest FAILED > > java.lang.Exception > > > > org.hibernate.test.locking.warning.LockNoneWarmingTest > > > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED > > java.lang.Exception > > > > 6307 tests completed, 4 failed, 327 skipped > > > > Yet the puzzling point: on ci.hibernate.org I don't see these failures > > happening, nor the testsuite time seems to have increased of any > > significant amount (it regularly completes in somewhere between 15 and > > 20 minutes). It takes me more than an hour to get this result on a > > machine which would normally complete the testsuite in 8 minutes, and > > I got the same 4 failures when re-running it a second time. > > > > Could other developers also please checkout master - specifically at > > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if > > it works allright for you and if the build time is consistent with the > > usual times for your machine? I need to understand what might be > > different between my workstation and the CI server. > > > > I might even have some great improvements ready to reduce the > > testsuite time, but I'm not comfortable in committing them in this > > context. > > > > Thanks, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Fri Apr 20 08:29:56 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 20 Apr 2018 12:29:56 +0000 Subject: [hibernate-dev] Analyzing the ORM testsuite In-Reply-To: References: <05f96743-4663-7279-ae5f-ee39cc2b42ed@hibernate.org> Message-ID: The postgres build is fine again, thanks for all the help! We re-enabled the CI job. On Fri, 20 Apr 2018, 01:14 Steve Ebersole, wrote: > > I checked - `build` does in fact pull in a bunch of tasks that you do not > care about (checkstyle, findbugs, etc). > > The build I just ran did take longer than I have been seeing - it took 16 > minutes, but that's not the magnitude you see. > > I mentioned performing test caused javadoc to be generated. I found the > culprit for that - hibernate-orm-modules. Any time tests > use hibernate-orm-modules, hibernate-orm-modules triggers a full build and > publish of the project's artifacts (jar, source jar, javadoc jar). This > accounts for at least some of the additional time. I think using build > rather than test probably accounts for the rest > > > On Thu, Apr 19, 2018 at 5:35 PM Sanne Grinovero > wrote: > >> On 19 April 2018 at 22:50, Chris Cranford wrote: >> > The entire build process under OpenJDK 8 here: >> > >> > BUILD SUCCESSFUL in 47m 26s >> > 251 actionable tasks: 233 executed, 18 up-to-date >> > >> > The only thing I noticed was that while executing the hibernate-core >> tests, >> > the memory consumption seemed quite high toward the end of the test >> suite, >> > particularly ~3.5GB memory consumed just to run the hibernate-core tests >> > alone and that FindBugs complained about some magic numbers on some zip >> > files while inspecting hibernate-osgi. >> > >> > Any idea if any substantial amount of that memory consumption related >> to the >> > test framework tracking the output/errors of those executed tests? >> >> I guess that confirms there's something specific to my environment. >> That's a great hint to have, thanks! >> >> Regarding the memory, yes I'm seeing the same. >90% of that is >> Mockito, I'm exploring some ideas to reduce its memory usage; I have >> some working experiments but I'm not happy with them: they make >> maintenance of tests error prone so tomorrow I'll try some >> alternatives. >> >> >> > >> > On 04/19/2018 05:20 PM, Sanne Grinovero wrote: >> > >> > On 19 April 2018 at 21:47, Chris Cranford wrote: >> > >> > Sanne - >> > >> > Are you running the build task or are you executing other more specific >> > tasks and noticing the slowness? >> > >> > Just running "gradle clean build" from the root. I had the same >> > results with OpenJDK 8 and 9, twice. Getting exactly the same failures >> > as before. >> > >> > Thanks! >> > >> > On 04/19/2018 04:25 PM, Steve Ebersole wrote: >> > >> > Nothing off the top of my head. The build time is in normal range on my >> > machine as of this morning (8 - 10 minutes). >> > >> > You mentioned a specific commit. Is that just when you noticed a >> change, >> > or do you suspect something in that commit? >> > >> > I'm not at computer right now, but when I get back I will check out that >> > commit and see if anything is strange locally. >> > >> > >> > >> > On Thu, Apr 19, 2018, 3:11 PM Sanne Grinovero >> wrote: >> > >> > Hi all, >> > >> > I'm trying to analyze the memory usage of current master of Hibernate >> > ORM; I started looking because of OOM errors on the PostgreSQL >> > testsuite (as mentioned in another thread). >> > >> > So far I've seen that Mockito is allocating a "lot of stuff"; I might >> > be able to improve some things in that area but it's a distraction >> > from my goal as clearly we use Mockito even when not running the >> > PostgreSQL backed tests and that seems to run fine. But it's polluting >> > the data reports so making it hard (and slow!) to verify if there is a >> > real issue. >> > >> > I could use some help to verify some tangential issues though; when >> > running the testsuite locally it's taking much longer than what I've >> > been used to see for the same testsuite some weeks ago, and I have >> > some failures - regularly seeing the same failures. >> > >> > These are triggered by running a default build, on H2: >> > >> > Task :hibernate-core:test >> > >> > org.hibernate.test.criteria.CriteriaLockingTest > >> > >> > >> testSetLockModeDifferentFromNONELogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> > FAILED >> > org.junit.runners.model.TestTimedOutException >> > >> > org.hibernate.test.criteria.CriteriaLockingTest > >> > >> > >> testSetLockModeNONEDoNotLogAWarnMessageWhenTheDialectUseFollowOnLockingIsTrue >> > FAILED >> > java.lang.Exception >> > >> > org.hibernate.test.criteria.CriteriaLockingTest > >> > org.hibernate.test.criteria.CriteriaLockingTest FAILED >> > java.lang.Exception >> > >> > org.hibernate.test.locking.warning.LockNoneWarmingTest > >> > org.hibernate.test.locking.warning.LockNoneWarmingTest FAILED >> > java.lang.Exception >> > >> > 6307 tests completed, 4 failed, 327 skipped >> > >> > Yet the puzzling point: on ci.hibernate.org I don't see these failures >> > happening, nor the testsuite time seems to have increased of any >> > significant amount (it regularly completes in somewhere between 15 and >> > 20 minutes). It takes me more than an hour to get this result on a >> > machine which would normally complete the testsuite in 8 minutes, and >> > I got the same 4 failures when re-running it a second time. >> > >> > Could other developers also please checkout master - specifically at >> > commit 291d4a3eeaa2ade32a42cfbcad5868b2114c34fe - and let me know if >> > it works allright for you and if the build time is consistent with the >> > usual times for your machine? I need to understand what might be >> > different between my workstation and the CI server. >> > >> > I might even have some great improvements ready to reduce the >> > testsuite time, but I'm not comfortable in committing them in this >> > context. >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gbadner at redhat.com Tue Apr 24 01:29:10 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 23 Apr 2018 22:29:10 -0700 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery Message-ID: SQL Server defines a function: DATEDIFF ( datepart , startdate , enddate ) [1] (This method still needs to be added to SQLServer2012Dialect.) datepart can be one of a variety of time values, e.g., day, week, year, etc. On SQL Server (at least) the value for datepart cannot be treated as a literal (enclosed in quotes) or bound as a parameter. This causes problems when using DATEDIFF in a CriteriaQuery. final Expression diff = cb.function("DATEDIFF", Integer.class, cb.literal("day"), ... ).as(Integer.class); SQL Server throws: com.microsoft.sqlserver.jdbc.SQLServerException: Invalid parameter 1 specified for datediff. There is no problem using the function in a query, as long as datepart is not enclosed in quotes or bound to the query: "select datediff( day, ... ) from ..." Is there some way to set a literal value using a CriteriaQuery that will not ultimately be enclosed in quotes or bound to a query? I've also been trying to find an integer constant that would be equivalent to 'day', but haven't had any luck. Anyone have an idea how this could be done with CriteriaQuery? Thanks, Gail [1] https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 From christian.beikov at gmail.com Tue Apr 24 02:45:01 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 24 Apr 2018 08:45:01 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: Message-ID: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Hey Gail, I usually register a dedicated SQLFunction for every time value in the Dialect and use these functions instead. So in your case, I'd have a "day" function and use it like final Expression diff = cb.function("DAY", Integer.class, ... ).as(Integer.class); The fuction will then render the SQL like it is supposed to be "select datediff( day, ... ) from ..." Although I'm not 100% sure that CriteriaBuilder.function properly resolves the function since I never used custom function with the JPA Criteria API directly, I'd at least expect it. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 24.04.2018 um 07:29 schrieb Gail Badner: > SQL Server defines a function: > > DATEDIFF ( datepart , startdate , enddate ) [1] > > (This method still needs to be added to SQLServer2012Dialect.) > > datepart can be one of a variety of time values, e.g., day, week, year, etc. > > On SQL Server (at least) the value for datepart cannot be treated as a > literal (enclosed in quotes) or bound as a parameter. > > This causes problems when using DATEDIFF in a CriteriaQuery. > > final Expression diff = cb.function("DATEDIFF", Integer.class, > cb.literal("day"), ... ).as(Integer.class); > > SQL Server throws: > com.microsoft.sqlserver.jdbc.SQLServerException: Invalid parameter 1 > specified for datediff. > > There is no problem using the function in a query, as long as datepart is > not enclosed in quotes or bound to the query: > > "select datediff( day, ... ) from ..." > > Is there some way to set a literal value using a CriteriaQuery that will > not ultimately be enclosed in quotes or bound to a query? > > I've also been trying to find an integer constant that would be equivalent > to 'day', but haven't had any luck. > > Anyone have an idea how this could be done with CriteriaQuery? > > Thanks, > Gail > > [1] > https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Tue Apr 24 09:21:16 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 24 Apr 2018 06:21:16 -0700 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: Yes, that should work with CriteriaQuery as well. It's a reasonable workaround. If JPA doesn't support this now, is it something that should be supported in the future? On Mon, Apr 23, 2018 at 11:45 PM, Christian Beikov < christian.beikov at gmail.com> wrote: > Hey Gail, > > I usually register a dedicated SQLFunction for every time value in the > Dialect and use these functions instead. So in your case, I'd have a > "day" function and use it like > > final Expression diff = cb.function("DAY", Integer.class, ... > ).as(Integer.class); > > The fuction will then render the SQL like it is supposed to be > > "select datediff( day, ... ) from ..." > > Although I'm not 100% sure that CriteriaBuilder.function properly > resolves the function since I never used custom function with the JPA > Criteria API directly, I'd at least expect it. > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 24.04.2018 um 07:29 schrieb Gail Badner: > > SQL Server defines a function: > > > > DATEDIFF ( datepart , startdate , enddate ) [1] > > > > (This method still needs to be added to SQLServer2012Dialect.) > > > > datepart can be one of a variety of time values, e.g., day, week, year, > etc. > > > > On SQL Server (at least) the value for datepart cannot be treated as a > > literal (enclosed in quotes) or bound as a parameter. > > > > This causes problems when using DATEDIFF in a CriteriaQuery. > > > > final Expression diff = cb.function("DATEDIFF", Integer.class, > > cb.literal("day"), ... ).as(Integer.class); > > > > SQL Server throws: > > com.microsoft.sqlserver.jdbc.SQLServerException: Invalid parameter 1 > > specified for datediff. > > > > There is no problem using the function in a query, as long as datepart is > > not enclosed in quotes or bound to the query: > > > > "select datediff( day, ... ) from ..." > > > > Is there some way to set a literal value using a CriteriaQuery that will > > not ultimately be enclosed in quotes or bound to a query? > > > > I've also been trying to find an integer constant that would be > equivalent > > to 'day', but haven't had any luck. > > > > Anyone have an idea how this could be done with CriteriaQuery? > > > > Thanks, > > Gail > > > > [1] > > https://docs.microsoft.com/en-us/sql/t-sql/functions/ > datediff-transact-sql?view=sql-server-2017 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From christian.beikov at gmail.com Tue Apr 24 09:36:22 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 24 Apr 2018 15:36:22 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: The JPA spec actually says the function invocation syntax can be used for database functions in 4.6.17.3. By "supported" you mean something like a note that says JPA providers may allow the invocation of JPA provider specific functions via that syntax? I'd love to go even further and standardize the definition of functions, but I guess that's not going to happen, so this seems to be a good compromise/first step. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 24.04.2018 um 15:21 schrieb Gail Badner: > Yes, that should work with CriteriaQuery as well. It's a reasonable > workaround. > > If JPA doesn't support this now, is it something that should be > supported in the future? > > On Mon, Apr 23, 2018 at 11:45 PM, Christian Beikov > > wrote: > > Hey Gail, > > I usually register a dedicated SQLFunction for every time value in > the > Dialect and use these functions instead. So in your case, I'd have a > "day" function and use it like > > final Expression diff = cb.function("DAY", Integer.class, > ... ).as(Integer.class); > > The fuction will then render the SQL like it is supposed to be > > "select datediff( day, ... ) from ..." > > Although I'm not 100% sure that CriteriaBuilder.function properly > resolves the function since I never used custom function with the JPA > Criteria API directly, I'd at least expect it. > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 24.04.2018 um 07:29 schrieb Gail Badner: > > SQL Server defines a function: > > > > DATEDIFF ( datepart , startdate , enddate )? [1] > > > > (This method still needs to be added to SQLServer2012Dialect.) > > > > datepart can be one of a variety of time values, e.g., day, > week, year, etc. > > > > On SQL Server (at least) the value for datepart cannot be > treated as a > > literal (enclosed in quotes) or bound as a parameter. > > > > This causes problems when using DATEDIFF in a CriteriaQuery. > > > > final Expression diff = cb.function("DATEDIFF", > Integer.class, > > cb.literal("day"), ... ).as(Integer.class); > > > > SQL Server throws: > > com.microsoft.sqlserver.jdbc.SQLServerException: Invalid parameter 1 > > specified for datediff. > > > > There is no problem using the function in a query, as long as > datepart is > > not enclosed in quotes or bound to the query: > > > > "select datediff( day, ... ) from ..." > > > > Is there some way to set a literal value using a CriteriaQuery > that will > > not ultimately be enclosed in quotes or bound to a query? > > > > I've also been trying to find an integer constant that would be > equivalent > > to 'day', but haven't had any luck. > > > > Anyone have an idea how this could be done with CriteriaQuery? > > > > Thanks, > > Gail > > > > [1] > > > https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From yoann at hibernate.org Tue Apr 24 09:42:12 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 24 Apr 2018 13:42:12 +0000 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of the latest NoORM IRC meeting: (15:40:17) jbott: Meeting ended Tue Apr 24 13:39:22 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) (15:40:17) jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-04-24-13.01.html (15:40:17) jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-04-24-13.01.txt (15:40:17) jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-04-24-13.01.log.html Cheers, -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From steve at hibernate.org Tue Apr 24 10:12:05 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 14:12:05 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: When you say "standardize the definition of functions", are you speaking about the which functions are defined as "built-in functions" or a mechanism in JPA to define `SQLFunction` overrides/extras? JPA already has quite a number of built-in functions defined: MIN, TRIM, LOWER, etc. I think we'd have a decent chance to get specific additions to the spec - especially EXTRACT. DATEDIFF would probably be a harder sell since it is not an ANSI SQL defined function - in ANSI SQL you'd accomplish this using date arithmetic and EXTRACT, something like extract( DAY, enddate - startdate ) Technically TIMESTAMP minus TIMESTAMP is supposed to return an INTERVAL (as opposed to an INTEGER) which itself can be an argument to EXTRACT. While DATEDIFF is not standardized in ANSI SQL, it is widely implemented across different databases. So honestly not sure how well various databases support DATEDIFF versus EXTRACT-from-INTERVAL We also try to standardize support for additional functions beyond JPA in Hibernate - so we have most Dialects implement YEAR, MONTH, DAY, HOUR, MINUTE, SECOND functions, e.g.: select year(appt.startTime) from Appointment appt On Tue, Apr 24, 2018 at 8:42 AM Christian Beikov wrote: > The JPA spec actually says the function invocation syntax can be used > for database functions in 4.6.17.3. > > By "supported" you mean something like a note that says JPA providers > may allow the invocation of JPA provider specific functions via that > syntax? I'd love to go even further and standardize the definition of > functions, but I guess that's not going to happen, so this seems to be a > good compromise/first step. > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 24.04.2018 um 15:21 schrieb Gail Badner: > > Yes, that should work with CriteriaQuery as well. It's a reasonable > > workaround. > > > > If JPA doesn't support this now, is it something that should be > > supported in the future? > > > > On Mon, Apr 23, 2018 at 11:45 PM, Christian Beikov > > > wrote: > > > > Hey Gail, > > > > I usually register a dedicated SQLFunction for every time value in > > the > > Dialect and use these functions instead. So in your case, I'd have a > > "day" function and use it like > > > > final Expression diff = cb.function("DAY", Integer.class, > > ... ).as(Integer.class); > > > > The fuction will then render the SQL like it is supposed to be > > > > "select datediff( day, ... ) from ..." > > > > Although I'm not 100% sure that CriteriaBuilder.function properly > > resolves the function since I never used custom function with the JPA > > Criteria API directly, I'd at least expect it. > > > > Mit freundlichen Gr??en, > > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 24.04.2018 um 07:29 schrieb Gail Badner: > > > SQL Server defines a function: > > > > > > DATEDIFF ( datepart , startdate , enddate ) [1] > > > > > > (This method still needs to be added to SQLServer2012Dialect.) > > > > > > datepart can be one of a variety of time values, e.g., day, > > week, year, etc. > > > > > > On SQL Server (at least) the value for datepart cannot be > > treated as a > > > literal (enclosed in quotes) or bound as a parameter. > > > > > > This causes problems when using DATEDIFF in a CriteriaQuery. > > > > > > final Expression diff = cb.function("DATEDIFF", > > Integer.class, > > > cb.literal("day"), ... ).as(Integer.class); > > > > > > SQL Server throws: > > > com.microsoft.sqlserver.jdbc.SQLServerException: Invalid parameter > 1 > > > specified for datediff. > > > > > > There is no problem using the function in a query, as long as > > datepart is > > > not enclosed in quotes or bound to the query: > > > > > > "select datediff( day, ... ) from ..." > > > > > > Is there some way to set a literal value using a CriteriaQuery > > that will > > > not ultimately be enclosed in quotes or bound to a query? > > > > > > I've also been trying to find an integer constant that would be > > equivalent > > > to 'day', but haven't had any luck. > > > > > > Anyone have an idea how this could be done with CriteriaQuery? > > > > > > Thanks, > > > Gail > > > > > > [1] > > > > > > https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 > > < > https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org hibernate-dev at lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Apr 24 10:16:35 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 14:16:35 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: Section 4.6.17.3 unfortunately also very strictly limits the sources of values for the arguments that can be passed to the functions using its `function(name, ...)` syntax. And unfortunately SQL keywords is not one of those. On Tue, Apr 24, 2018 at 9:12 AM Steve Ebersole wrote: > When you say "standardize the definition of functions", are you speaking > about the which functions are defined as "built-in functions" or a > mechanism in JPA to define `SQLFunction` overrides/extras? > > JPA already has quite a number of built-in functions defined: MIN, TRIM, > LOWER, etc. I think we'd have a decent chance to get specific additions to > the spec - especially EXTRACT. DATEDIFF would probably be a harder sell > since it is not an ANSI SQL defined function - in ANSI SQL you'd accomplish > this using date arithmetic and EXTRACT, something like > > extract( DAY, enddate - startdate ) > > Technically TIMESTAMP minus TIMESTAMP is supposed to return an INTERVAL > (as opposed to an INTEGER) which itself can be an argument to EXTRACT. > > While DATEDIFF is not standardized in ANSI SQL, it is widely implemented > across different databases. So honestly not sure how well various > databases support DATEDIFF versus EXTRACT-from-INTERVAL > > > We also try to standardize support for additional functions beyond JPA in > Hibernate - so we have most Dialects implement YEAR, MONTH, DAY, HOUR, > MINUTE, SECOND functions, e.g.: > > select year(appt.startTime) from Appointment appt > > > > > > On Tue, Apr 24, 2018 at 8:42 AM Christian Beikov < > christian.beikov at gmail.com> wrote: > >> The JPA spec actually says the function invocation syntax can be used >> for database functions in 4.6.17.3. >> >> By "supported" you mean something like a note that says JPA providers >> may allow the invocation of JPA provider specific functions via that >> syntax? I'd love to go even further and standardize the definition of >> functions, but I guess that's not going to happen, so this seems to be a >> good compromise/first step. >> >> >> Mit freundlichen Gr??en, >> ------------------------------------------------------------------------ >> *Christian Beikov* >> Am 24.04.2018 um 15:21 schrieb Gail Badner: >> > Yes, that should work with CriteriaQuery as well. It's a reasonable >> > workaround. >> > >> > If JPA doesn't support this now, is it something that should be >> > supported in the future? >> > >> > On Mon, Apr 23, 2018 at 11:45 PM, Christian Beikov >> > > wrote: >> > >> > Hey Gail, >> > >> > I usually register a dedicated SQLFunction for every time value in >> > the >> > Dialect and use these functions instead. So in your case, I'd have a >> > "day" function and use it like >> > >> > final Expression diff = cb.function("DAY", Integer.class, >> > ... ).as(Integer.class); >> > >> > The fuction will then render the SQL like it is supposed to be >> > >> > "select datediff( day, ... ) from ..." >> > >> > Although I'm not 100% sure that CriteriaBuilder.function properly >> > resolves the function since I never used custom function with the >> JPA >> > Criteria API directly, I'd at least expect it. >> > >> > Mit freundlichen Gr??en, >> > >> ------------------------------------------------------------------------ >> > *Christian Beikov* >> > Am 24.04.2018 um 07:29 schrieb Gail Badner: >> > > SQL Server defines a function: >> > > >> > > DATEDIFF ( datepart , startdate , enddate ) [1] >> > > >> > > (This method still needs to be added to SQLServer2012Dialect.) >> > > >> > > datepart can be one of a variety of time values, e.g., day, >> > week, year, etc. >> > > >> > > On SQL Server (at least) the value for datepart cannot be >> > treated as a >> > > literal (enclosed in quotes) or bound as a parameter. >> > > >> > > This causes problems when using DATEDIFF in a CriteriaQuery. >> > > >> > > final Expression diff = cb.function("DATEDIFF", >> > Integer.class, >> > > cb.literal("day"), ... ).as(Integer.class); >> > > >> > > SQL Server throws: >> > > com.microsoft.sqlserver.jdbc.SQLServerException: Invalid >> parameter 1 >> > > specified for datediff. >> > > >> > > There is no problem using the function in a query, as long as >> > datepart is >> > > not enclosed in quotes or bound to the query: >> > > >> > > "select datediff( day, ... ) from ..." >> > > >> > > Is there some way to set a literal value using a CriteriaQuery >> > that will >> > > not ultimately be enclosed in quotes or bound to a query? >> > > >> > > I've also been trying to find an integer constant that would be >> > equivalent >> > > to 'day', but haven't had any luck. >> > > >> > > Anyone have an idea how this could be done with CriteriaQuery? >> > > >> > > Thanks, >> > > Gail >> > > >> > > [1] >> > > >> > >> https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 >> > < >> https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 >> > >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org > hibernate-dev at lists.jboss.org> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > >> > >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From christian.beikov at gmail.com Tue Apr 24 10:28:59 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 24 Apr 2018 16:28:59 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: <04ef2c9a-7995-7907-2be8-46406e4dbe78@gmail.com> I'm speaking about a mechanism to define what Hibernate calls `SQLFunction` in a JPA standard way. Every JPA provider has this concept. I even implemented a JPA provider abstraction for this in Blaze-Persistence and it works pretty well. How does the specification process in the Eclipse Foundation work, or is it not yet defined? I'd be curious what it takes for an idea or a feature to be considered. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 24.04.2018 um 16:12 schrieb Steve Ebersole: > When you say "standardize the definition of functions", are you > speaking about the which functions are defined as "built-in functions" > or a mechanism in JPA to define `SQLFunction` overrides/extras? > > JPA already has quite a number of built-in functions defined: MIN, > TRIM, LOWER, etc.? I think we'd have a decent chance to get specific > additions to the spec - especially EXTRACT.? DATEDIFF would probably > be a harder sell since it is not an ANSI SQL defined function - in > ANSI SQL you'd accomplish this using date arithmetic and EXTRACT, > something like > > extract( DAY, enddate - startdate ) > > Technically TIMESTAMP minus TIMESTAMP is supposed to return an > INTERVAL (as opposed to an INTEGER) which itself can be an argument to > EXTRACT. > > While DATEDIFF is not standardized in ANSI SQL, it is widely > implemented across different databases.? So honestly not sure how well > various databases support DATEDIFF versus EXTRACT-from-INTERVAL > > > We also try to standardize support for additional functions beyond JPA > in Hibernate - so we have most Dialects implement YEAR, MONTH, DAY, > HOUR, MINUTE, SECOND functions, e.g.: > > select year(appt.startTime) from Appointment appt > > > > > > On Tue, Apr 24, 2018 at 8:42 AM Christian Beikov > > wrote: > > The JPA spec actually says the function invocation syntax can be used > for database functions in 4.6.17.3. > > By "supported" you mean something like a note that says JPA providers > may allow the invocation of JPA provider specific functions via that > syntax? I'd love to go even further and standardize the definition of > functions, but I guess that's not going to happen, so this seems > to be a > good compromise/first step. > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 24.04.2018 um 15:21 schrieb Gail Badner: > > Yes, that should work with CriteriaQuery as well. It's a reasonable > > workaround. > > > > If JPA doesn't support this now, is it something that should be > > supported in the future? > > > > On Mon, Apr 23, 2018 at 11:45 PM, Christian Beikov > > > >> wrote: > > > >? ? ?Hey Gail, > > > >? ? ?I usually register a dedicated SQLFunction for every time > value in > >? ? ?the > >? ? ?Dialect and use these functions instead. So in your case, > I'd have a > >? ? ?"day" function and use it like > > > >? ? ?final Expression diff = cb.function("DAY", > Integer.class, > >? ? ?... ).as(Integer.class); > > > >? ? ?The fuction will then render the SQL like it is supposed to be > > > >? ? ?"select datediff( day, ... ) from ..." > > > >? ? ?Although I'm not 100% sure that CriteriaBuilder.function > properly > >? ? ?resolves the function since I never used custom function > with the JPA > >? ? ?Criteria API directly, I'd at least expect it. > > > >? ? ?Mit freundlichen Gr??en, > > > ?------------------------------------------------------------------------ > >? ? ?*Christian Beikov* > >? ? ?Am 24.04.2018 um 07:29 schrieb Gail Badner: > >? ? ?> SQL Server defines a function: > >? ? ?> > >? ? ?> DATEDIFF ( datepart , startdate , enddate ) [1] > >? ? ?> > >? ? ?> (This method still needs to be added to SQLServer2012Dialect.) > >? ? ?> > >? ? ?> datepart can be one of a variety of time values, e.g., day, > >? ? ?week, year, etc. > >? ? ?> > >? ? ?> On SQL Server (at least) the value for datepart cannot be > >? ? ?treated as a > >? ? ?> literal (enclosed in quotes) or bound as a parameter. > >? ? ?> > >? ? ?> This causes problems when using DATEDIFF in a CriteriaQuery. > >? ? ?> > >? ? ?> final Expression diff = cb.function("DATEDIFF", > >? ? ?Integer.class, > >? ? ?> cb.literal("day"), ... ).as(Integer.class); > >? ? ?> > >? ? ?> SQL Server throws: > >? ? ?> com.microsoft.sqlserver.jdbc.SQLServerException: Invalid > parameter 1 > >? ? ?> specified for datediff. > >? ? ?> > >? ? ?> There is no problem using the function in a query, as long as > >? ? ?datepart is > >? ? ?> not enclosed in quotes or bound to the query: > >? ? ?> > >? ? ?> "select datediff( day, ... ) from ..." > >? ? ?> > >? ? ?> Is there some way to set a literal value using a CriteriaQuery > >? ? ?that will > >? ? ?> not ultimately be enclosed in quotes or bound to a query? > >? ? ?> > >? ? ?> I've also been trying to find an integer constant that > would be > >? ? ?equivalent > >? ? ?> to 'day', but haven't had any luck. > >? ? ?> > >? ? ?> Anyone have an idea how this could be done with CriteriaQuery? > >? ? ?> > >? ? ?> Thanks, > >? ? ?> Gail > >? ? ?> > >? ? ?> [1] > >? ? ?> > > > https://docs.microsoft.com/en-us/sql/t-sql/functions/datediff-transact-sql?view=sql-server-2017 > >? ? > ? > >? ? ?> _______________________________________________ > >? ? ?> hibernate-dev mailing list > >? ? ?> hibernate-dev at lists.jboss.org > > > > >? ? ?> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >? ? ? > > > >? ? ?_______________________________________________ > >? ? ?hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >? ? ? > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Apr 24 10:29:34 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 14:29:34 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: On Tue, Apr 24, 2018 at 8:45 AM Gail Badner wrote: > Yes, that should work with CriteriaQuery as well. It's a reasonable > workaround. > > If JPA doesn't support this now, is it something that should be supported > in the future? The problem with defining support for this in the spec is that it is relying on Hibernate's "SQL function registry" and its `SQLFunction` contract. I seriously doubt we'd get all the EG members to agree to some standardization of anything like a `SQLFunction` contract. I think proposing to add additional functions to the spec as "built-in" is probably more likely. I can especially see EXTRACT being likely. Maybe DATEDIFF. Oracle for sure does not support DATEDIFF, but it does support the EXTRACT-from-INTERVAL approach. Anyone know offhand other databases which to not define DATEIDFF? I personally think having DATEDIFF defined as "built-in" is the best option as the provider can always map that to EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do that by mapping EXTRACT-from-INTERVAL to DATEDIFF. From steve at hibernate.org Tue Apr 24 10:33:59 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 14:33:59 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: JPA is technically under the old JCP still AFAIK. So for now the process would be the same it has always been. I just do not see how this would ever get agreed upon for a standardized contract - it is so very dependent upon how the provider models the query (SQM e.g.) versus the specific mechanism they use to render it (SQL AST). On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole wrote: > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner wrote: > >> Yes, that should work with CriteriaQuery as well. It's a reasonable >> workaround. >> >> If JPA doesn't support this now, is it something that should be supported >> in the future? > > > The problem with defining support for this in the spec is that it is > relying on Hibernate's "SQL function registry" and its `SQLFunction` > contract. I seriously doubt we'd get all the EG members to agree to some > standardization of anything like a `SQLFunction` contract. > > I think proposing to add additional functions to the spec as "built-in" is > probably more likely. I can especially see EXTRACT being likely. Maybe > DATEDIFF. Oracle for sure does not support DATEDIFF, but it does support > the EXTRACT-from-INTERVAL approach. Anyone know offhand other databases > which to not define DATEIDFF? > > I personally think having DATEDIFF defined as "built-in" is the best > option as the provider can always map that to EXTRACT-from-INTERVAL for > Oracle, etal - its much harder to do that by mapping EXTRACT-from-INTERVAL > to DATEDIFF. > From christian.beikov at gmail.com Tue Apr 24 10:56:41 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 24 Apr 2018 16:56:41 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> Message-ID: <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Maybe we should wait until it transitioned to Eclipse then? Or do you think it might make sense to start discussions already? The API could be String based by default but allow to "unwrap" to do something provider specific. If the providers model requires it, the String could be parsed by the provider. Imagine an API like the following interface SQLFunction { ? ExpressionType getType(FunctionContext ctx, List argumentTypes); ? Expression render(FunctionContext ctx, List arguments); ? interface FunctionContext { ??? ExpressionType getExpressionType(Class javaType); ??? Expression getExpression(String expressionString); ??? T unwrap(Class clz); ? } ? interface ExpressionType { ??? Class getJavaType(); ??? T unwrap(Class clz); ? } ? interface Expression { ??? String getExpressionString(); ??? T unwrap(Class clz); ? } } That's just a rough idea of how it could look. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 24.04.2018 um 16:33 schrieb Steve Ebersole: > JPA is technically under the old JCP still AFAIK. So for now the > process would be the same it has always been. > > I just do not see how this would ever get agreed upon for a > standardized contract - it is so very dependent upon how the provider > models the query (SQM e.g.) versus the specific mechanism they use to > render it (SQL AST). > > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole > wrote: > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > wrote: > > Yes, that should work with CriteriaQuery as well. It's a > reasonable > workaround. > > If JPA doesn't support this now, is it something that should > be supported > in the future? > > > The problem with defining support for this in the spec is that it > is relying on Hibernate's "SQL function registry" and its > `SQLFunction` contract.? I seriously doubt we'd get all the EG > members to agree to some standardization of anything like a > `SQLFunction` contract. > > I think proposing to add additional functions to the spec as > "built-in" is probably more likely.? I can especially see EXTRACT > being likely.? Maybe DATEDIFF. Oracle for sure does not support > DATEDIFF, but it does support the EXTRACT-from-INTERVAL approach.? > ?Anyone know offhand other databases which to not define DATEIDFF? > > I personally think having DATEDIFF defined as "built-in" is the > best option as the provider can always map that to > EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do > that by mapping EXTRACT-from-INTERVAL to DATEDIFF. > From gbadner at redhat.com Tue Apr 24 14:18:15 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 24 Apr 2018 11:18:15 -0700 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: When I asked about whether JPA should support this in the future, I was thinking along the lines of adding something like the following to javax.persistence.criteria.CriteriaBuilder: Keyword keyword(String value); // rendered as a String without quotes or: Expression literal(String value, encloseInQuotes); On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < christian.beikov at gmail.com> wrote: > Maybe we should wait until it transitioned to Eclipse then? Or do you > think it might make sense to start discussions already? > > The API could be String based by default but allow to "unwrap" to do > something provider specific. If the providers model requires it, the > String could be parsed by the provider. > > Imagine an API like the following > > interface SQLFunction { > ExpressionType getType(FunctionContext ctx, List > argumentTypes); > Expression render(FunctionContext ctx, List arguments); > > interface FunctionContext { > ExpressionType getExpressionType(Class javaType); > Expression getExpression(String expressionString); > T unwrap(Class clz); > } > > interface ExpressionType { > Class getJavaType(); > T unwrap(Class clz); > } > > interface Expression { > String getExpressionString(); > T unwrap(Class clz); > } > } > > That's just a rough idea of how it could look. > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: > > JPA is technically under the old JCP still AFAIK. So for now the > > process would be the same it has always been. > > > > I just do not see how this would ever get agreed upon for a > > standardized contract - it is so very dependent upon how the provider > > models the query (SQM e.g.) versus the specific mechanism they use to > > render it (SQL AST). > > > > > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole > > wrote: > > > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > > wrote: > > > > Yes, that should work with CriteriaQuery as well. It's a > > reasonable > > workaround. > > > > If JPA doesn't support this now, is it something that should > > be supported > > in the future? > > > > > > The problem with defining support for this in the spec is that it > > is relying on Hibernate's "SQL function registry" and its > > `SQLFunction` contract. I seriously doubt we'd get all the EG > > members to agree to some standardization of anything like a > > `SQLFunction` contract. > > > > I think proposing to add additional functions to the spec as > > "built-in" is probably more likely. I can especially see EXTRACT > > being likely. Maybe DATEDIFF. Oracle for sure does not support > > DATEDIFF, but it does support the EXTRACT-from-INTERVAL approach. > > Anyone know offhand other databases which to not define DATEIDFF? > > > > I personally think having DATEDIFF defined as "built-in" is the > > best option as the provider can always map that to > > EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do > > that by mapping EXTRACT-from-INTERVAL to DATEDIFF. > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Apr 24 16:43:31 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 20:43:31 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: I'd personally not like that approach. I think specific registrations (for extract and datediff) are better options On Tue, Apr 24, 2018, 1:18 PM Gail Badner wrote: > When I asked about whether JPA should support this in the future, I was > thinking along the lines of adding something like the following > to javax.persistence.criteria.CriteriaBuilder: > > Keyword keyword(String value); // rendered as a String without quotes > > or: > > Expression literal(String value, encloseInQuotes); > > > On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < > christian.beikov at gmail.com> wrote: > > > Maybe we should wait until it transitioned to Eclipse then? Or do you > > think it might make sense to start discussions already? > > > > The API could be String based by default but allow to "unwrap" to do > > something provider specific. If the providers model requires it, the > > String could be parsed by the provider. > > > > Imagine an API like the following > > > > interface SQLFunction { > > ExpressionType getType(FunctionContext ctx, List > > argumentTypes); > > Expression render(FunctionContext ctx, List arguments); > > > > interface FunctionContext { > > ExpressionType getExpressionType(Class javaType); > > Expression getExpression(String expressionString); > > T unwrap(Class clz); > > } > > > > interface ExpressionType { > > Class getJavaType(); > > T unwrap(Class clz); > > } > > > > interface Expression { > > String getExpressionString(); > > T unwrap(Class clz); > > } > > } > > > > That's just a rough idea of how it could look. > > > > Mit freundlichen Gr??en, > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: > > > JPA is technically under the old JCP still AFAIK. So for now the > > > process would be the same it has always been. > > > > > > I just do not see how this would ever get agreed upon for a > > > standardized contract - it is so very dependent upon how the provider > > > models the query (SQM e.g.) versus the specific mechanism they use to > > > render it (SQL AST). > > > > > > > > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole > > > wrote: > > > > > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > > > wrote: > > > > > > Yes, that should work with CriteriaQuery as well. It's a > > > reasonable > > > workaround. > > > > > > If JPA doesn't support this now, is it something that should > > > be supported > > > in the future? > > > > > > > > > The problem with defining support for this in the spec is that it > > > is relying on Hibernate's "SQL function registry" and its > > > `SQLFunction` contract. I seriously doubt we'd get all the EG > > > members to agree to some standardization of anything like a > > > `SQLFunction` contract. > > > > > > I think proposing to add additional functions to the spec as > > > "built-in" is probably more likely. I can especially see EXTRACT > > > being likely. Maybe DATEDIFF. Oracle for sure does not support > > > DATEDIFF, but it does support the EXTRACT-from-INTERVAL approach. > > > Anyone know offhand other databases which to not define DATEIDFF? > > > > > > I personally think having DATEDIFF defined as "built-in" is the > > > best option as the provider can always map that to > > > EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do > > > that by mapping EXTRACT-from-INTERVAL to DATEDIFF. > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Tue Apr 24 17:57:11 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 24 Apr 2018 14:57:11 -0700 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: I just want to make sure that what I'm suggesting is clear. datediff would be registered as a function: registerFunction( "datediff", new StandardSQLFunction( "datediff", StandardBasicTypes.INTEGER ) ); Then, to specify datediff with the keyword, day, as the first parameter (rendered without quotes): final Expression diff = cb.function("DATEDIFF", Integer.class, cb.keyword("day"), ... ).as(Integer.class); On Tue, Apr 24, 2018 at 1:43 PM, Steve Ebersole wrote: > I'd personally not like that approach. I think specific registrations > (for extract and datediff) are better options > > > On Tue, Apr 24, 2018, 1:18 PM Gail Badner wrote: > >> When I asked about whether JPA should support this in the future, I was >> thinking along the lines of adding something like the following >> to javax.persistence.criteria.CriteriaBuilder: >> >> Keyword keyword(String value); // rendered as a String without quotes >> >> or: >> >> Expression literal(String value, encloseInQuotes); >> >> >> On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < >> christian.beikov at gmail.com> wrote: >> >> > Maybe we should wait until it transitioned to Eclipse then? Or do you >> > think it might make sense to start discussions already? >> > >> > The API could be String based by default but allow to "unwrap" to do >> > something provider specific. If the providers model requires it, the >> > String could be parsed by the provider. >> > >> > Imagine an API like the following >> > >> > interface SQLFunction { >> > ExpressionType getType(FunctionContext ctx, List >> > argumentTypes); >> > Expression render(FunctionContext ctx, List arguments); >> > >> > interface FunctionContext { >> > ExpressionType getExpressionType(Class javaType); >> > Expression getExpression(String expressionString); >> > T unwrap(Class clz); >> > } >> > >> > interface ExpressionType { >> > Class getJavaType(); >> > T unwrap(Class clz); >> > } >> > >> > interface Expression { >> > String getExpressionString(); >> > T unwrap(Class clz); >> > } >> > } >> > >> > That's just a rough idea of how it could look. >> > >> > Mit freundlichen Gr??en, >> > ------------------------------------------------------------ >> ------------ >> > *Christian Beikov* >> > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: >> > > JPA is technically under the old JCP still AFAIK. So for now the >> > > process would be the same it has always been. >> > > >> > > I just do not see how this would ever get agreed upon for a >> > > standardized contract - it is so very dependent upon how the provider >> > > models the query (SQM e.g.) versus the specific mechanism they use to >> > > render it (SQL AST). >> > > >> > > >> > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole > > > > wrote: >> > > >> > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > > > > wrote: >> > > >> > > Yes, that should work with CriteriaQuery as well. It's a >> > > reasonable >> > > workaround. >> > > >> > > If JPA doesn't support this now, is it something that should >> > > be supported >> > > in the future? >> > > >> > > >> > > The problem with defining support for this in the spec is that it >> > > is relying on Hibernate's "SQL function registry" and its >> > > `SQLFunction` contract. I seriously doubt we'd get all the EG >> > > members to agree to some standardization of anything like a >> > > `SQLFunction` contract. >> > > >> > > I think proposing to add additional functions to the spec as >> > > "built-in" is probably more likely. I can especially see EXTRACT >> > > being likely. Maybe DATEDIFF. Oracle for sure does not support >> > > DATEDIFF, but it does support the EXTRACT-from-INTERVAL approach. >> > > Anyone know offhand other databases which to not define DATEIDFF? >> > > >> > > I personally think having DATEDIFF defined as "built-in" is the >> > > best option as the provider can always map that to >> > > EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do >> > > that by mapping EXTRACT-from-INTERVAL to DATEDIFF. >> > > >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Tue Apr 24 18:11:32 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 22:11:32 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: Yep, it was clear On Tue, Apr 24, 2018 at 4:57 PM Gail Badner wrote: > I just want to make sure that what I'm suggesting is clear. > > datediff would be registered as a function: > > registerFunction( "datediff", > new StandardSQLFunction( "datediff", StandardBasicTypes.INTEGER ) > ); > > Then, to specify datediff with the keyword, day, as the first parameter > (rendered without quotes): > > final Expression diff = cb.function("DATEDIFF", Integer.class, > cb.keyword("day"), ... ).as(Integer.class); > > > On Tue, Apr 24, 2018 at 1:43 PM, Steve Ebersole > wrote: > >> I'd personally not like that approach. I think specific registrations >> (for extract and datediff) are better options >> >> >> On Tue, Apr 24, 2018, 1:18 PM Gail Badner wrote: >> >>> When I asked about whether JPA should support this in the future, I was >>> thinking along the lines of adding something like the following >>> to javax.persistence.criteria.CriteriaBuilder: >>> >>> Keyword keyword(String value); // rendered as a String without quotes >>> >>> or: >>> >>> Expression literal(String value, encloseInQuotes); >>> >>> >>> On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < >>> christian.beikov at gmail.com> wrote: >>> >>> > Maybe we should wait until it transitioned to Eclipse then? Or do you >>> > think it might make sense to start discussions already? >>> > >>> > The API could be String based by default but allow to "unwrap" to do >>> > something provider specific. If the providers model requires it, the >>> > String could be parsed by the provider. >>> > >>> > Imagine an API like the following >>> > >>> > interface SQLFunction { >>> > ExpressionType getType(FunctionContext ctx, List >>> > argumentTypes); >>> > Expression render(FunctionContext ctx, List arguments); >>> > >>> > interface FunctionContext { >>> > ExpressionType getExpressionType(Class javaType); >>> > Expression getExpression(String expressionString); >>> > T unwrap(Class clz); >>> > } >>> > >>> > interface ExpressionType { >>> > Class getJavaType(); >>> > T unwrap(Class clz); >>> > } >>> > >>> > interface Expression { >>> > String getExpressionString(); >>> > T unwrap(Class clz); >>> > } >>> > } >>> > >>> > That's just a rough idea of how it could look. >>> > >>> > Mit freundlichen Gr??en, >>> > >>> ------------------------------------------------------------------------ >>> > *Christian Beikov* >>> > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: >>> > > JPA is technically under the old JCP still AFAIK. So for now the >>> > > process would be the same it has always been. >>> > > >>> > > I just do not see how this would ever get agreed upon for a >>> > > standardized contract - it is so very dependent upon how the provider >>> > > models the query (SQM e.g.) versus the specific mechanism they use to >>> > > render it (SQL AST). >>> > > >>> > > >>> > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole >> > > > wrote: >>> > > >>> > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner >> > > > wrote: >>> > > >>> > > Yes, that should work with CriteriaQuery as well. It's a >>> > > reasonable >>> > > workaround. >>> > > >>> > > If JPA doesn't support this now, is it something that should >>> > > be supported >>> > > in the future? >>> > > >>> > > >>> > > The problem with defining support for this in the spec is that it >>> > > is relying on Hibernate's "SQL function registry" and its >>> > > `SQLFunction` contract. I seriously doubt we'd get all the EG >>> > > members to agree to some standardization of anything like a >>> > > `SQLFunction` contract. >>> > > >>> > > I think proposing to add additional functions to the spec as >>> > > "built-in" is probably more likely. I can especially see EXTRACT >>> > > being likely. Maybe DATEDIFF. Oracle for sure does not support >>> > > DATEDIFF, but it does support the EXTRACT-from-INTERVAL approach. >>> > > Anyone know offhand other databases which to not define >>> DATEIDFF? >>> > > >>> > > I personally think having DATEDIFF defined as "built-in" is the >>> > > best option as the provider can always map that to >>> > > EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do >>> > > that by mapping EXTRACT-from-INTERVAL to DATEDIFF. >>> > > >>> > >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> > From christian.beikov at gmail.com Tue Apr 24 18:20:50 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 25 Apr 2018 00:20:50 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: I don't like this either. It simply feels wrong as this is a "provider specific" keyword i.e. some DBMS might not even support DATEDIFF. IMO when we decide to abstract over the DBMS specifics by introducing a HQL DATEDIFF or specifying a JPQL DATEDIFF, we could just as well introduce separate functions which would ultimately look a lot cleaner. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 25.04.2018 um 00:11 schrieb Steve Ebersole: > Yep, it was clear > > On Tue, Apr 24, 2018 at 4:57 PM Gail Badner > wrote: > > I just want to make sure that what I'm suggesting is clear. > > datediff would be registered as a function: > > registerFunction("datediff", > new StandardSQLFunction("datediff", StandardBasicTypes.INTEGER ) > ); > > Then, to specify datediff with the keyword, day, as the first > parameter (rendered without quotes): > > final Expression diff = cb.function("DATEDIFF", > Integer.class, cb.keyword("day"), ... ).as(Integer.class); > > > On Tue, Apr 24, 2018 at 1:43 PM, Steve Ebersole > > wrote: > > I'd personally not like that approach.? I think specific > registrations (for extract and datediff) are better options > > > On Tue, Apr 24, 2018, 1:18 PM Gail Badner > wrote: > > When I asked about whether JPA should support this in the > future, I was > thinking along the lines of adding something like the > following > to javax.persistence.criteria.CriteriaBuilder: > > Keyword keyword(String value);? // rendered as a String > without quotes > > or: > > Expression literal(String value, encloseInQuotes); > > > On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < > christian.beikov at gmail.com > > wrote: > > > Maybe we should wait until it transitioned to Eclipse > then? Or do you > > think it might make sense to start discussions already? > > > > The API could be String based by default but allow to > "unwrap" to do > > something provider specific. If the providers model > requires it, the > > String could be parsed by the provider. > > > > Imagine an API like the following > > > > interface SQLFunction { > >? ? ExpressionType getType(FunctionContext ctx, > List > > argumentTypes); > >? ? Expression render(FunctionContext ctx, > List arguments); > > > >? ? interface FunctionContext { > >? ? ? ExpressionType getExpressionType(Class javaType); > >? ? ? Expression getExpression(String expressionString); > >? ? ? T unwrap(Class clz); > >? ? } > > > >? ? interface ExpressionType { > >? ? ? Class getJavaType(); > >? ? ? T unwrap(Class clz); > >? ? } > > > >? ? interface Expression { > >? ? ? String getExpressionString(); > >? ? ? T unwrap(Class clz); > >? ? } > > } > > > > That's just a rough idea of how it could look. > > > > Mit freundlichen Gr??en, > > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: > > > JPA is technically under the old JCP still AFAIK. So > for now the > > > process would be the same it has always been. > > > > > > I just do not see how this would ever get agreed upon > for a > > > standardized contract - it is so very dependent upon > how the provider > > > models the query (SQM e.g.) versus the specific > mechanism they use to > > > render it (SQL AST). > > > > > > > > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole > > > > >> wrote: > > > > > >? ? ?On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > > > >? ? ? >> wrote: > > > > > >? ? ? ? ?Yes, that should work with CriteriaQuery as > well. It's a > > >? ? ? ? ?reasonable > > >? ? ? ? ?workaround. > > > > > >? ? ? ? ?If JPA doesn't support this now, is it > something that should > > >? ? ? ? ?be supported > > >? ? ? ? ?in the future? > > > > > > > > >? ? ?The problem with defining support for this in the > spec is that it > > >? ? ?is relying on Hibernate's "SQL function registry" > and its > > >? ? ?`SQLFunction` contract.? I seriously doubt we'd > get all the EG > > >? ? ?members to agree to some standardization of > anything like a > > >? ? ?`SQLFunction` contract. > > > > > >? ? ?I think proposing to add additional functions to > the spec as > > >? ? ?"built-in" is probably more likely.? I can > especially see EXTRACT > > >? ? ?being likely.? Maybe DATEDIFF. Oracle for sure > does not support > > >? ? ?DATEDIFF, but it does support the > EXTRACT-from-INTERVAL approach. > > >? ? ? Anyone know offhand other databases which to not > define DATEIDFF? > > > > > >? ? ?I personally think having DATEDIFF defined as > "built-in" is the > > >? ? ?best option as the provider can always map that to > > >? ? ?EXTRACT-from-INTERVAL for Oracle, etal - its much > harder to do > > >? ? ?that by mapping EXTRACT-from-INTERVAL to DATEDIFF. > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Tue Apr 24 18:25:24 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 22:25:24 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: What I was proposing instead was to treat extract and hopefully datediff as first-class citizens: cb.extract( DateField.DAY, startDate ).as( Integer.class ); cb.extract( DateField.DAY, endDate - startDate ).as( Integer.class ); cb.datediff( DateField.DAY, endDate, startDate ).as( Integer.class ); s.createQuery( "... where extract( DAY, startDate ) ..." ); s.createQuery( "... where extract( DAY, endDate - startDate ) ..." ); s.createQuery( "... where datediff( DAY, endDate, startDate ) ..." ); On Tue, Apr 24, 2018 at 5:11 PM Steve Ebersole wrote: > Yep, it was clear > > On Tue, Apr 24, 2018 at 4:57 PM Gail Badner wrote: > >> I just want to make sure that what I'm suggesting is clear. >> >> datediff would be registered as a function: >> >> registerFunction( "datediff", >> new StandardSQLFunction( "datediff", StandardBasicTypes.INTEGER ) >> ); >> >> Then, to specify datediff with the keyword, day, as the first parameter >> (rendered without quotes): >> >> final Expression diff = cb.function("DATEDIFF", Integer.class, >> cb.keyword("day"), ... ).as(Integer.class); >> >> >> On Tue, Apr 24, 2018 at 1:43 PM, Steve Ebersole >> wrote: >> >>> I'd personally not like that approach. I think specific registrations >>> (for extract and datediff) are better options >>> >>> >>> On Tue, Apr 24, 2018, 1:18 PM Gail Badner wrote: >>> >>>> When I asked about whether JPA should support this in the future, I was >>>> thinking along the lines of adding something like the following >>>> to javax.persistence.criteria.CriteriaBuilder: >>>> >>>> Keyword keyword(String value); // rendered as a String without quotes >>>> >>>> or: >>>> >>>> Expression literal(String value, encloseInQuotes); >>>> >>>> >>>> On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < >>>> christian.beikov at gmail.com> wrote: >>>> >>>> > Maybe we should wait until it transitioned to Eclipse then? Or do you >>>> > think it might make sense to start discussions already? >>>> > >>>> > The API could be String based by default but allow to "unwrap" to do >>>> > something provider specific. If the providers model requires it, the >>>> > String could be parsed by the provider. >>>> > >>>> > Imagine an API like the following >>>> > >>>> > interface SQLFunction { >>>> > ExpressionType getType(FunctionContext ctx, List >>>> > argumentTypes); >>>> > Expression render(FunctionContext ctx, List arguments); >>>> > >>>> > interface FunctionContext { >>>> > ExpressionType getExpressionType(Class javaType); >>>> > Expression getExpression(String expressionString); >>>> > T unwrap(Class clz); >>>> > } >>>> > >>>> > interface ExpressionType { >>>> > Class getJavaType(); >>>> > T unwrap(Class clz); >>>> > } >>>> > >>>> > interface Expression { >>>> > String getExpressionString(); >>>> > T unwrap(Class clz); >>>> > } >>>> > } >>>> > >>>> > That's just a rough idea of how it could look. >>>> > >>>> > Mit freundlichen Gr??en, >>>> > >>>> ------------------------------------------------------------------------ >>>> > *Christian Beikov* >>>> > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: >>>> > > JPA is technically under the old JCP still AFAIK. So for now the >>>> > > process would be the same it has always been. >>>> > > >>>> > > I just do not see how this would ever get agreed upon for a >>>> > > standardized contract - it is so very dependent upon how the >>>> provider >>>> > > models the query (SQM e.g.) versus the specific mechanism they use >>>> to >>>> > > render it (SQL AST). >>>> > > >>>> > > >>>> > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole >>> > > > wrote: >>>> > > >>>> > > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner >>> > > > wrote: >>>> > > >>>> > > Yes, that should work with CriteriaQuery as well. It's a >>>> > > reasonable >>>> > > workaround. >>>> > > >>>> > > If JPA doesn't support this now, is it something that should >>>> > > be supported >>>> > > in the future? >>>> > > >>>> > > >>>> > > The problem with defining support for this in the spec is that >>>> it >>>> > > is relying on Hibernate's "SQL function registry" and its >>>> > > `SQLFunction` contract. I seriously doubt we'd get all the EG >>>> > > members to agree to some standardization of anything like a >>>> > > `SQLFunction` contract. >>>> > > >>>> > > I think proposing to add additional functions to the spec as >>>> > > "built-in" is probably more likely. I can especially see >>>> EXTRACT >>>> > > being likely. Maybe DATEDIFF. Oracle for sure does not support >>>> > > DATEDIFF, but it does support the EXTRACT-from-INTERVAL >>>> approach. >>>> > > Anyone know offhand other databases which to not define >>>> DATEIDFF? >>>> > > >>>> > > I personally think having DATEDIFF defined as "built-in" is the >>>> > > best option as the provider can always map that to >>>> > > EXTRACT-from-INTERVAL for Oracle, etal - its much harder to do >>>> > > that by mapping EXTRACT-from-INTERVAL to DATEDIFF. >>>> > > >>>> > >>>> > _______________________________________________ >>>> > hibernate-dev mailing list >>>> > hibernate-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >> From christian.beikov at gmail.com Tue Apr 24 18:39:25 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 25 Apr 2018 00:39:25 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> Message-ID: <2f930c80-18a4-20f3-848c-2ee6a63e1deb@gmail.com> That's a possibility indeed, but there will most likely always be some nice function that uses a weird keyword syntax for which there is no first class support. So even if we propose this, IMO we should still also propose to add a note to the function invocation syntax section, that a function may resolve to a JPA vendor defined funciton as well. This would be like a "last resort" to use a function at least in a "standard way". If the JPA vendor doesn't define the desired function, it's up to the user to making use of JPA vendor specific APIs for registering the function. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 25.04.2018 um 00:25 schrieb Steve Ebersole: > What I was proposing instead was to treat extract and hopefully > datediff as first-class citizens: > > cb.extract( DateField.DAY, startDate ).as( Integer.class ); > cb.extract( DateField.DAY, endDate - startDate ).as( Integer.class ); > cb.datediff( DateField.DAY, endDate, startDate ).as( Integer.class ); > > s.createQuery( "... where extract( DAY, startDate ) ..." ); > s.createQuery( "... where extract( DAY, endDate - startDate ) ..." ); > s.createQuery( "... where datediff( DAY, endDate, startDate ) ..." ); > > > > On Tue, Apr 24, 2018 at 5:11 PM Steve Ebersole > wrote: > > Yep, it was clear > > On Tue, Apr 24, 2018 at 4:57 PM Gail Badner > wrote: > > I just want to make sure that what I'm suggesting is clear. > > datediff would be registered as a function: > > registerFunction("datediff", > new StandardSQLFunction("datediff", StandardBasicTypes.INTEGER ) > ); > > Then, to specify datediff with the keyword, day, as the first > parameter (rendered without quotes): > > final Expression diff = cb.function("DATEDIFF", > Integer.class, cb.keyword("day"), ... ).as(Integer.class); > > > On Tue, Apr 24, 2018 at 1:43 PM, Steve Ebersole > > wrote: > > I'd personally not like that approach.? I think specific > registrations (for extract and datediff) are better options > > > On Tue, Apr 24, 2018, 1:18 PM Gail Badner > > wrote: > > When I asked about whether JPA should support this in > the future, I was > thinking along the lines of adding something like the > following > to javax.persistence.criteria.CriteriaBuilder: > > Keyword keyword(String value);? // rendered as a > String without quotes > > or: > > Expression literal(String value, encloseInQuotes); > > > On Tue, Apr 24, 2018 at 7:56 AM, Christian Beikov < > christian.beikov at gmail.com > > wrote: > > > Maybe we should wait until it transitioned to > Eclipse then? Or do you > > think it might make sense to start discussions already? > > > > The API could be String based by default but allow > to "unwrap" to do > > something provider specific. If the providers model > requires it, the > > String could be parsed by the provider. > > > > Imagine an API like the following > > > > interface SQLFunction { > >? ? ExpressionType getType(FunctionContext ctx, > List > > argumentTypes); > >? ? Expression render(FunctionContext ctx, > List arguments); > > > >? ? interface FunctionContext { > >? ? ? ExpressionType getExpressionType(Class > javaType); > >? ? ? Expression getExpression(String expressionString); > >? ? ? T unwrap(Class clz); > >? ? } > > > >? ? interface ExpressionType { > >? ? ? Class getJavaType(); > >? ? ? T unwrap(Class clz); > >? ? } > > > >? ? interface Expression { > >? ? ? String getExpressionString(); > >? ? ? T unwrap(Class clz); > >? ? } > > } > > > > That's just a rough idea of how it could look. > > > > Mit freundlichen Gr??en, > > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 24.04.2018 um 16:33 schrieb Steve Ebersole: > > > JPA is technically under the old JCP still AFAIK. > So for now the > > > process would be the same it has always been. > > > > > > I just do not see how this would ever get agreed > upon for a > > > standardized contract - it is so very dependent > upon how the provider > > > models the query (SQM e.g.) versus the specific > mechanism they use to > > > render it (SQL AST). > > > > > > > > > On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole > > > > >> wrote: > > > > > >? ? ?On Tue, Apr 24, 2018 at 8:45 AM Gail Badner > > > >? ? ? >> wrote: > > > > > >? ? ? ? ?Yes, that should work with CriteriaQuery > as well. It's a > > >? ? ? ? ?reasonable > > >? ? ? ? ?workaround. > > > > > >? ? ? ? ?If JPA doesn't support this now, is it > something that should > > >? ? ? ? ?be supported > > >? ? ? ? ?in the future? > > > > > > > > >? ? ?The problem with defining support for this in > the spec is that it > > >? ? ?is relying on Hibernate's "SQL function > registry" and its > > >? ? ?`SQLFunction` contract.? I seriously doubt > we'd get all the EG > > >? ? ?members to agree to some standardization of > anything like a > > >? ? ?`SQLFunction` contract. > > > > > >? ? ?I think proposing to add additional functions > to the spec as > > >? ? ?"built-in" is probably more likely.? I can > especially see EXTRACT > > >? ? ?being likely.? Maybe DATEDIFF. Oracle for sure > does not support > > >? ? ?DATEDIFF, but it does support the > EXTRACT-from-INTERVAL approach. > > >? ? ? Anyone know offhand other databases which to > not define DATEIDFF? > > > > > >? ? ?I personally think having DATEDIFF defined as > "built-in" is the > > >? ? ?best option as the provider can always map that to > > >? ? ?EXTRACT-from-INTERVAL for Oracle, etal - its > much harder to do > > >? ? ?that by mapping EXTRACT-from-INTERVAL to DATEDIFF. > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Tue Apr 24 18:46:46 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 24 Apr 2018 22:46:46 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: <2f930c80-18a4-20f3-848c-2ee6a63e1deb@gmail.com> References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> <2f930c80-18a4-20f3-848c-2ee6a63e1deb@gmail.com> Message-ID: On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov wrote: > That's a possibility indeed, but there will most likely always be some > nice function that uses a weird keyword syntax for which there is no > first class support. > And not only that but some databases allow extensions to the SQL spec as to what can be extracted. So using an enum is nice, but limiting > So even if we propose this, IMO we should still also propose to add a > note to the function invocation syntax section, that a function may > resolve to a JPA vendor defined funciton as well. This would be like a > "last resort" to use a function at least in a "standard way". If the JPA > vendor doesn't define the desired function, it's up to the user to > making use of JPA vendor specific APIs for registering the function. > I'm not sure what this means From christian.beikov at gmail.com Wed Apr 25 02:51:32 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 25 Apr 2018 08:51:32 +0200 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> <2f930c80-18a4-20f3-848c-2ee6a63e1deb@gmail.com> Message-ID: <648c8fac-03cf-c756-4fe1-bb5cf52b42ac@gmail.com> Am 25.04.2018 um 00:46 schrieb Steve Ebersole: > > > On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov > > wrote: > > That's a possibility indeed, but there will most likely always be > some > nice function that uses a weird keyword syntax for which there is no > first class support. > > > And not only that but some databases allow extensions to the SQL spec > as to what can be extracted.? So using an enum is nice, but limiting > > So even if we propose this, IMO we should still also propose to add a > note to the function invocation syntax section, that a function may > resolve to a JPA vendor defined funciton as well. This would be > like a > "last resort" to use a function at least in a "standard way". If > the JPA > vendor doesn't define the desired function, it's up to the user to > making use of JPA vendor specific APIs for registering the function. > > > I'm not sure what this means That means that section 4.6.17.3 should be changed to allow for FUNCTION('XYZ', arg1, ...) to resolve to a JPA vendor specific function like the ones registered in a Hibernate Dialect. To me it seems that currently the wording requires to pass this through to the SQL directly as XYZ(arg1). This would allow the use of user defined SQLFunctions through the JPA Criteria API. From steve at hibernate.org Wed Apr 25 09:07:28 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 25 Apr 2018 13:07:28 +0000 Subject: [hibernate-dev] How to deal with a constant in CriteriaQuery In-Reply-To: <648c8fac-03cf-c756-4fe1-bb5cf52b42ac@gmail.com> References: <478b35cd-758d-0bcd-5e5c-b0c6bf17ee74@gmail.com> <0e0f4e7e-6b22-e5fb-86a5-6bd083ac6792@gmail.com> <2f930c80-18a4-20f3-848c-2ee6a63e1deb@gmail.com> <648c8fac-03cf-c756-4fe1-bb5cf52b42ac@gmail.com> Message-ID: We can propose it. Personally I do not think that section explicitly precludes what we do, but I agree that it does imply the function invocation should be "passed through". I think this might be difficult to get consensus on though - just a quick look at EclipseLink and TopLink show that they define a completely different mechanism for such "provider treated" function calls (OPERATION rather than FUNCTION), so I doubt there will be much support for changing the wording here. We'll see... I think we should standardize a number of HQL functions beyond the JPA ones across Dialects (we have Dialect coverage for many of these already): - Date / Time (already standardized across Dialects) - year - month - day - hour - minute - second - Date / Time (can be done through datetime arithmetic) - datediff - dateadd - Convert / Cast - to_char - to_number - to_date - Trigonometry - cos - sin - tan - ... As for other cases like "date field" where we need to be able to refer to SQL-y things, we should add some kind of support for that generically imo. This is something I've wanted to do for some time - I just don't know a good syntax yet. I had thought to use braces (e.g. `extract( {day} from startDate)`) but we use braces already for a few other things. We could take a page from JDBC (escape syntax) and have `extract( {sql day} from startDate)` - that makes it more syntactically understandable. On Wed, Apr 25, 2018 at 1:51 AM Christian Beikov wrote: > Am 25.04.2018 um 00:46 schrieb Steve Ebersole: > > > > > > On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov > > > wrote: > > > > That's a possibility indeed, but there will most likely always be > > some > > nice function that uses a weird keyword syntax for which there is no > > first class support. > > > > > > And not only that but some databases allow extensions to the SQL spec > > as to what can be extracted. So using an enum is nice, but limiting > > > > So even if we propose this, IMO we should still also propose to add a > > note to the function invocation syntax section, that a function may > > resolve to a JPA vendor defined funciton as well. This would be > > like a > > "last resort" to use a function at least in a "standard way". If > > the JPA > > vendor doesn't define the desired function, it's up to the user to > > making use of JPA vendor specific APIs for registering the function. > > > > > > I'm not sure what this means > That means that section 4.6.17.3 should be changed to allow for > FUNCTION('XYZ', arg1, ...) to resolve to a JPA vendor specific function > like the ones registered in a Hibernate Dialect. To me it seems that > currently the wording requires to pass this through to the SQL directly > as XYZ(arg1). This would allow the use of user defined SQLFunctions > through the JPA Criteria API. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Thu Apr 26 05:05:39 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 26 Apr 2018 10:05:39 +0100 Subject: [hibernate-dev] Starting 5.2.17 release Message-ID: *Please do not push anything to 5.2 branch.Thanks,Andrea* From andrea at hibernate.org Thu Apr 26 07:44:21 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 26 Apr 2018 12:44:21 +0100 Subject: [hibernate-dev] Hibernate ORM 5.2.17.Final has been released Message-ID: *For details:http://in.relation.to/2018/04/26/hibernate-orm-5217-final-release * From steve at hibernate.org Fri Apr 27 12:29:57 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 27 Apr 2018 16:29:57 +0000 Subject: [hibernate-dev] ORM 5.3.0.CR2 released Message-ID: I apologize for the delay in getting this released. The delay comes from work to restore any unintentionally lost binary and behavioral compatibility between 5.3, 5.2 and 5.1. But it was definitely worthwhile work. Details at http://in.relation.to/2018/04/27/hibernate-orm-530-cr2-release/ From guillaume.smet at gmail.com Mon Apr 30 12:09:17 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Apr 2018 18:09:17 +0200 Subject: [hibernate-dev] Releases and CI setup Message-ID: Hi, So, as expected, I'm not very happy with the new CI setup when doing releases. The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1, 5,2, master-h2, master-check) which takes all the slave bandwidth we have. Note that I'm talking of ORM because it's where the issue is the most prominent but I'm pretty sure I would have the same issue with HV, considering we now have quite a few maintenance branches, except that the HV builds are faster. So I would say: - either we fix the issue we have with all the branches being tested for each commit that we discussed numerous times - or we need a mechanism to start specific slaves for releases - but I'm not sure it's fast enough tbh Because it's really annoying. Especially when you have to run your release job 3 times in a row due to SF.net issues... Releasing is already a tedious process, let's not make it even more tedious. (yeah I know it's not the first time I complain about it but it's really worse than it was before) -- Guillaume From steve at hibernate.org Mon Apr 30 14:27:28 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 30 Apr 2018 18:27:28 +0000 Subject: [hibernate-dev] Releases and CI setup In-Reply-To: References: Message-ID: Then we should move to a CI server that is not erroneously triggering jobs it should not. On Mon, Apr 30, 2018 at 11:30 AM Guillaume Smet wrote: > Hi, > > So, as expected, I'm not very happy with the new CI setup when doing > releases. > > The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1, > 5,2, master-h2, master-check) which takes all the slave bandwidth we have. > > Note that I'm talking of ORM because it's where the issue is the most > prominent but I'm pretty sure I would have the same issue with HV, > considering we now have quite a few maintenance branches, except that the > HV builds are faster. > > So I would say: > - either we fix the issue we have with all the branches being tested for > each commit that we discussed numerous times > - or we need a mechanism to start specific slaves for releases - but I'm > not sure it's fast enough tbh > > Because it's really annoying. Especially when you have to run your release > job 3 times in a row due to SF.net issues... > > Releasing is already a tedious process, let's not make it even more > tedious. > > (yeah I know it's not the first time I complain about it but it's really > worse than it was before) > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Apr 30 14:34:32 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 30 Apr 2018 19:34:32 +0100 Subject: [hibernate-dev] Releases and CI setup In-Reply-To: References: Message-ID: Starting a new slave only takes 3 minutes, but I believe it has to be a "manual start" from its admin dashboard as Jenkins's scaling plugin is limited. Fixing the Jenkins triggers would be my preference. Alternatively: - we could look at pipelines - run all jobs within Docker -> improved isolation would allow us to run N builds per machine - combine these: run it all on Openshift On 30 April 2018 at 17:09, Guillaume Smet wrote: > Hi, > > So, as expected, I'm not very happy with the new CI setup when doing > releases. > > The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1, > 5,2, master-h2, master-check) which takes all the slave bandwidth we have. > > Note that I'm talking of ORM because it's where the issue is the most > prominent but I'm pretty sure I would have the same issue with HV, > considering we now have quite a few maintenance branches, except that the > HV builds are faster. > > So I would say: > - either we fix the issue we have with all the branches being tested for > each commit that we discussed numerous times > - or we need a mechanism to start specific slaves for releases - but I'm > not sure it's fast enough tbh > > Because it's really annoying. Especially when you have to run your release > job 3 times in a row due to SF.net issues... > > Releasing is already a tedious process, let's not make it even more tedious. > > (yeah I know it's not the first time I complain about it but it's really > worse than it was before) > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Mon Apr 30 14:42:15 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 30 Apr 2018 20:42:15 +0200 Subject: [hibernate-dev] Releases and CI setup In-Reply-To: References: Message-ID: On Mon, Apr 30, 2018 at 8:34 PM, Sanne Grinovero wrote: > Starting a new slave only takes 3 minutes, but I believe it has to be > a "manual start" from its admin dashboard as Jenkins's scaling plugin > is limited. > > Fixing the Jenkins triggers would be my preference. > Yeah, last time we discussed this on HipChat, I have all the useful pointers. The code changes to the official plugin would be minimal. The only thing I'm worried about is how we would maintain this plugin. Alternatively: > - we could look at pipelines > How would they solve the issue? > - run all jobs within Docker -> improved isolation would allow us to > run N builds per machine > Would that help? I.e. are the machines we start powerful enough to run several jobs in parallel? I suspect, it wouldn't change the issue, just change the numbers of servers we would need (which might be good anyway but is not related to the issue at hand). -- Guillaume From daltodavide at gmail.com Mon Apr 30 14:53:09 2018 From: daltodavide at gmail.com (Davide D'Alto) Date: Mon, 30 Apr 2018 19:53:09 +0100 Subject: [hibernate-dev] Releases and CI setup In-Reply-To: References: Message-ID: Using docker might be a nice idea if the machines are powerful enough. I will just mention it here but for the release only we can also not use Jenkins and run the command we need from the terminal of ci.hibernate.org. We already have the scripts ready so it shouldn't be too hard. If the Jenkins plugin doesn't work the way we need I don't feel like creating our own branch and I will consider it only if it's about sending a PR somewhere. But all this won't solve the problem with SourceForge that seems to be the main reason we see failures lately. On Mon, Apr 30, 2018 at 7:42 PM, Guillaume Smet wrote: > On Mon, Apr 30, 2018 at 8:34 PM, Sanne Grinovero > wrote: > >> Starting a new slave only takes 3 minutes, but I believe it has to be >> a "manual start" from its admin dashboard as Jenkins's scaling plugin >> is limited. >> >> Fixing the Jenkins triggers would be my preference. >> > > Yeah, last time we discussed this on HipChat, I have all the useful > pointers. The code changes to the official plugin would be minimal. The > only thing I'm worried about is how we would maintain this plugin. > > Alternatively: >> - we could look at pipelines >> > > How would they solve the issue? > > >> - run all jobs within Docker -> improved isolation would allow us to >> run N builds per machine >> > > Would that help? I.e. are the machines we start powerful enough to run > several jobs in parallel? > > I suspect, it wouldn't change the issue, just change the numbers of servers > we would need (which might be good anyway but is not related to the issue > at hand). > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev