Re: [hibernate-dev] Auto-registering the cacheable entities and collections

That is unintended, likely from the L2C service changes. Yes we should change that to match the old behavior. On Wed, May 30, 2018 at 9:43 AM Vlad Mihalcea wrote: > Hi, > > While upgrading my Hibernate testing repository to 5.3, I realized that we > no longer auto-register the 2nd-level cache

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

lback" is what happens when the user does not explicitly specify. That is what both the RegionFactoryInitiator and JtaPlatformInitiator in hibernate-jipijapa do On Tue, May 29, 2018 at 12:49 PM Scott Marlow wrote: > > > On 05/29/2018 10:05 AM, Steve Ebersole wrote: > > On Tue

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Tue, May 29, 2018 at 8:38 AM Scott Marlow wrote: > > On 05/29/2018 08:48 AM, Steve Ebersole wrote: > > By "non-jpa container managed deployments" you mean injecting Hibernate > > Sessions? Otherwise, I am not sure what this is supposed to mean. Nor > > wh

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

fix is merged to orm master branch, which should be in 5.3.2, as soon as > that is available. > > > On Sun, May 27, 2018, 7:06 PM Steve Ebersole wrote: > >> JBossStandalone is meant for use of JBoss Transactions outside of >> WildFly. Why are we using it inside Wild

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

JBossStandalone is meant for use of JBoss Transactions outside of WildFly. Why are we using it inside WildFly. Inside WildFly, jipijapa ought to be defining that however it needs through a custom JtaPlatform and probably the JtaPlatformInitiator. On Sun, May 27, 2018, 3:58 PM Sanne Grinovero

Re: [hibernate-dev] 6.0 Design Doc

;ch...@hibernate.org> wrote: > In case anyone tries to locate this file more recently, its now under: > > https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/design/sql-engine.adoc > > On 05/23/2018 01:55 PM, Steve Ebersole wrote: > > Andrea and I have spent some tim

Re: [hibernate-dev] Multiple ResultSets from JDBC execution

specific method > (Hibernate API) should we instruct Hibernate to process all ResultSets, in > the same way, using a single ResultSetMapping. > > Vlad > > > > On Fri, May 25, 2018 at 12:15 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> I'm not saying to have

Re: [hibernate-dev] Preparing the 5.3.1 release

t;volunteer" :) > > Thanks! > > On 23 May 2018 at 23:20, Steve Ebersole <st...@hibernate.org> > <st...@hibernate.org> wrote: > > If someone can do the release, +1 from me > > On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero <sa...@hibernate.org> &

Re: [hibernate-dev] Preparing the 5.3.1 release

If someone can do the release, +1 from me On Wed, May 23, 2018 at 5:11 PM Sanne Grinovero wrote: > Hi Steve, > > are we free to release a 5.3.1 this weekend? > > As I mentioned in the parallel thread "WildFly 14 requirements for > Hibernate libraries", we can still get some

[hibernate-dev] 6.0 Design Doc

Andrea and I have spent some time getting the SQL execution design doc up-to-date. Would be nice to get any feedback. Thanks :) https://github.com/sebersole/hibernate-core/blob/wip/6.0-merge/sql-engine-design.adoc ___ hibernate-dev mailing list

[hibernate-dev] Multiple ResultSets from JDBC execution

Execution of procedure calls, function calls and anonymous blocks can all lead to JDBC returning us multiple ResultSets. To account for this (for the first 2 anyway) JPA allows defining multiple ResultSetMapping references for the StoredProcesdureQuery. Alternatively, it allows specifying

Re: [hibernate-dev] Suggestions for alternative due to deprecation of Configuration access in ServiceContributor...

By "read only" I assume you mean immutable (aka, Collections#immutableMap)? If so, sure, that is a decent solution... On Wed, May 23, 2018 at 7:55 AM Scott Marlow wrote: > For the WildFly use of ServiceContributor [1], which registers for each > SF/EMF, the 2lc

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

> .getBean( MetadataBuilderContributor.class ); > } > > MetadataBuilderContributor metadataBuilderContributor = > metadataBuilderContributorManagedBean > .getBeanInstance(); > > Am I using it the wrong way, or do we need to check the BeanContainer > first to make sure it's not null b

Re: [hibernate-dev] Stride

You can't "do your job" without yet another way to get notified of CI job status? I'm confused - did Jenkins remove all of its other forms of notification? ;) Seriously though, I've never understood this desire to have yet another communications "inbox" spammed by automated notifications - and

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

n the end, I thought of a more generic approach to for JPA > > >> bootstrapping > > >> > which, not only allows us to register SqlFunctions, but we can > > >> apply other > > >> > changes on the MetadataBuilder object used during bootstrap.

[hibernate-dev] Stride

I got an email from Atlassian this morning about the migration from HipChat to Stride. Basically they have not gotten Stride feature-complete in terms of HipChat which is the trigger for the mass migration. However, they are reaching out to all waiting teams to see if any want to migrate anyway.

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

this topic: > > https://discourse.hibernate.org/t/i-cant-use-group-concat-in-queries/752/14 > > And, realized that I was wrong about suggesting doing it via the > Integrator mechanism (since the Metamodel is already frozen by the time we > execute the Integrator). > > Vl

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

This should maybe wait for 6.0. We are ditching SQLFunction in favor of a more AST-friendly contract. Beyond that, go for it. On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea wrote: > Hi, > > I realized that only the native Hibernate bootstrapping mechanism allows > for

Re: [hibernate-dev] Differences in ORM exception handling in 5.1 vs 5.3

I'd really rather not get into supporting arbitrary ExceptionConverter strategies.. JPA-compliant and then "native"-compliant are plenty. I thought we had added a `hibernate.jpa.compliance.exception` setting, but I see it is not there. On Tue, May 15, 2018 at 1:52 PM Gail Badner

[hibernate-dev] Hibernate ORM 5.3.0.Final release

I am finishing up the 5.3.0.Final release tasks - http://in.relation.to/2018/05/14/hibernate-orm-530-final-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Scheduling issues

I am trying to determine where we are with 5.3 Final. So I look in Jira and the original 4 issues I added to Final (mainly verification tasks) have jumped to 19. This makes it impossible to plan. So please, if you are not actively working on an issue or are not planning on finishing it within a

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

>> Deferring initialization of these batch loaders is one option, but that just really delays the memory consumption. Personally, if it were my app I'd rather that sizing be done up front rather than over the course of the next few hours or weeks as the system continues to run. Not sure how

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

Loaders were designed to be an encapsulation of the query (the SQL, how to build and execute the PreparedStatement) and the "load plan" (how the ResultSet is processed). 4.2 changed how this last part is represented, but overall the design is the same it always has been. The problem is that

Re: [hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

Yeah, we have been having a chat about this on HipChat On Thu, May 3, 2018 at 12:54 PM Gail Badner wrote: > I just looked at that thread and it's comparing 3.6 to 5.3.CR2... > > On Thu, May 3, 2018 at 4:17 AM, Vlad Mihalcea > wrote: > > > I asked

Re: [hibernate-dev] Releases and CI setup

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

[hibernate-dev] ORM 5.3.0.CR2 released

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/

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

at makes it more syntactically understandable. On Wed, Apr 25, 2018 at 1:51 AM Christian Beikov <christian.bei...@gmail.com> wrote: > Am 25.04.2018 um 00:46 schrieb Steve Ebersole: > > > > > > On Tue, Apr 24, 2018 at 5:43 PM Christian Beikov > > <chr

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

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

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

); 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 <s

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

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"

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

); > > } > > } > > > > 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

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

mechanism they use to render it (SQL AST). On Tue, Apr 24, 2018 at 9:29 AM Steve Ebersole <st...@hibernate.org> wrote: > On Tue, Apr 24, 2018 at 8:45 AM Gail Badner <gbad...@redhat.com> wrote: > >> Yes, that should work with CriteriaQuery as well. It's a reasonable >> wo

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

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

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

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 <st...@hibernate.

Re: [hibernate-dev] How to deal with a constant in CriteriaQuery

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

Re: [hibernate-dev] Analyzing the ORM testsuite

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 b

Re: [hibernate-dev] Analyzing the ORM testsuite

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

[hibernate-dev] Fwd: Build failed in Jenkins: hibernate-orm-master-pgsql #1038

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:

Re: [hibernate-dev] HHH-8944 - ColumnTransformer handling is too aggressive in qualifying "column names"

https://github.com/hibernate/hibernate-orm/pull/2237 On Thu, Apr 12, 2018 at 7:45 AM Steve Ebersole <st...@hibernate.org> wrote: > Anyone know of places where we document ColumnTransformer read-fragment > handling as qualifying columns other than the column the transformer is > at

[hibernate-dev] HHH-8944 - ColumnTransformer handling is too aggressive in qualifying "column names"

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,

Re: [hibernate-dev] HipChat / JIRA / Atlassian account(s) login

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:

Re: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3

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 <sa...@hibernate.org> wrote: > On 5 April 2018 at 22:03, Steve Ebersole <st...@hibernate.org> wrote: > > I am assuming tha

Re: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3

nly 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 <st...@hibernate.org> > wrote: > > > >> Are these in addition to the original documentation

Re: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3

//hibernate.atlassian.net/browse/HHH-12424=D=1522883266264000=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

Re: [hibernate-dev] New report for API incompatibilities between 5.1 and 5.3

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

Re: [hibernate-dev] Why hibernate-jcache is not enough (for Infinispan)

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

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

en be relatively easy to > > do. Or it could already be fixed. > > Good to know, thanks. I might explore that next week. > > Sanne > > > > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> Not sure. animal-s

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

tive tool which can do better? > > Thanks, > Sanne > > > On 22 March 2018 at 14:22, Steve Ebersole <st...@hibernate.org> wrote: > > Yes there were "lots of differences" but a vast majority of them are > > false-positives, not just those listed in the alr

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

Yes there were "lots of differences" but a vast majority of them are false-positives, not just those listed in the already massive "false positives" section. I've been going through the non-"false positive" section and "resolving" specific items (via strike-through) with either (1) link to Jira

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

you help us understand. None of the SPI changes have been merged > in master yet? > > On 22 March 2018 at 13:39, Steve Ebersole <st...@hibernate.org> wrote: > > Then you'll have to wait. Seems like snapshot is better than waiting > but of > > course yo

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

Like a snapshot? On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 22 March 2018 at 12:18, Steve Ebersole <st...@hibernate.org> wrote: > > There is already a branch that contains these changes that they can work > > with... no need to w

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

There is already a branch that contains these changes that they can work with... no need to wait for a CR. I still want to let Andrea finish the work on TypeConfiguration and BootstrapContext before we cut CR2. On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero wrote: >

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

Great! On Wed, Mar 21, 2018 at 6:21 PM Gail Badner <gbad...@redhat.com> wrote: > Worked like a charm. > Thanks! > > On Wed, Mar 21, 2018 at 11:07 AM, Gail Badner <gbad...@redhat.com> wrote: > >> OK, I'll give it a try. Thanks! >> >> On Wed,

[hibernate-dev] Defaultable service strategies

Thoughts on allowing certain services to be defaulted to the single implementor registered with the `StrategySelector` service when there is just one? For example, when resolving the RegionFactory unless both (a) `hibernate.cache.region.factory_class` and (b) one of

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

. > > How do I disable the up-to-date checks? > > On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> You could have avoided that up front by disabling the up-to-date checks. >> But now your original local jars are gone... >>

[hibernate-dev] Cache testing & JCache

The initial hibernate-jcache code would create JCache Cache instance "on the fly" as they were needed if not already defined. As part of a discussion about JCache support, it was agreed that this should not happen. To be clear... the integration code calls

Re: [hibernate-dev] JPA Events

It is actually very unclear. Look at the wording... "...update operations to *entity* data...". So clearly it boils down to your definition of "entity data" and what is being updated, as Oliver mentions as well. We take the interpretation that since we are not updating the entity table here, we

Re: [hibernate-dev] 5.3 - hibernate-ehcache

On Thu, Mar 15, 2018 at 9:30 AM Radim Vansa wrote: > Before Infinispan provides native implementation to 5.3/6.0 SPIs, JCache > is a good way to bridge the gap. So if you're setting up a matrix > testing, adding Infinispan JCache provider would give us some confidence > that

Re: [hibernate-dev] 5.3 - hibernate-ehcache

I'd have to look at the tests :) On Thu, Mar 15, 2018 at 9:46 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 15 March 2018 at 13:58, Steve Ebersole <st...@hibernate.org> wrote: > > On Thu, Mar 15, 2018 at 8:47 AM Sanne Grinovero <sa...@hibernate.org> > wrote:

Re: [hibernate-dev] 5.3 - hibernate-ehcache

Inline On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 15 March 2018 at 13:04, Steve Ebersole <st...@hibernate.org> wrote: > > Given the changes to the second-level cache SPI, I wonder if we want to > > take that as an oppor

[hibernate-dev] 5.3 - hibernate-ehcache

Given the changes to the second-level cache SPI, I wonder if we want to take that as an opportunity to consider dropping the `hibernate-ehcache` module? There are a few reasons I am considering this... 1. We have the JCache integration in place and users can use Ehcache via that support

Re: [hibernate-dev] Joins over type variable defined assocations NPE problems

I think it is ok to disallow implicit downcasting in cases where the downcast is non-deterministic. From you example domain, I think it is ok to disallow the implicit downcast in : `from BaseEntity e where e.relation.id = ...' with either a specific error ("cannot implicitly downcast BaseEntity

Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions

Out of curiosity, do you have a link to this new java.sql.ShardingKey feature? Other than that, I agree with Sanne - multiple jars (with proper classifier once y'all publish your drivers) is the best option On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan wrote: >

Re: [hibernate-dev] Proxying the Session: a requirement ?

- no more :) On Fri, Mar 9, 2018 at 7:14 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 9 March 2018 at 13:09, Steve Ebersole <st...@hibernate.org> wrote: > > I think most environments would proxy the JPA contracts if anything. For > > Session we do offer the "

Re: [hibernate-dev] Proxying the Session: a requirement ?

I think most environments would proxy the JPA contracts if anything. For Session we do offer the "base delegator" for a delegation solution rather than proxying. All told, unless we hear differently I'd say you are safe to break proxying of the Session. Assuming of course you fix the

Re: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid

ere. But generally speaking I think that's valid when the association is not marked optional > Thanks, > Gail > > On Thu, Mar 8, 2018 at 11:22 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> For sure our model can handle this mapping, although maybe only from th

Re: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid

For sure our model can handle this mapping, although maybe only from the other side (that's generally the more natural mapping) - internally it's called a "logical many-to-one". Personally I'd say there is nothing wrong with the mapping per-se. On Wed, Mar 7, 2018 at 4:36 PM Gail Badner

Re: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method

On Wed, Mar 7, 2018 at 6:59 PM Sanne Grinovero wrote: > Hi all, > > good news on the backwards compatibility; David suggested we could use > his "bridger" tool to have the Session API binary compatible with > older versions. > - https://github.com/dmlloyd/bridger > Wow,

Re: [hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results

to track down where/why execution count is not incremented. On Wed, Mar 7, 2018 at 11:44 AM andrea boriero <and...@hibernate.org> wrote: > is the first check assertEquals( qs.getCacheHitCount(), 0 ); ? > > On 7 March 2018 at 17:12, Steve Ebersole <st...@hibernate.org> wr

[hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results

I am trying to finish up these caching and stats related changes, but am currently fighting a few remaining test failures. In my initial investigation IMO some of these tests are wrong, but hoped someone(s) else could check may expectation/belief. E.g. have a look at

Re: [hibernate-dev] 5.3 finalization plan

My preference is for the providers to handle that, yes. I have already spoken with the Ehcache devs. I have reached out to the Infinispan team but have not heard back On Mon, Mar 5, 2018 at 10:46 AM Scott Marlow <smar...@redhat.com> wrote: > > > On 03/01/2018 02:37 PM, Steve

Re: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises?

Sure, I think using DeprecationLogger is a good short-term option. On Mon, Mar 5, 2018 at 9:32 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 5 March 2018 at 15:24, Steve Ebersole <st...@hibernate.org> wrote: > > Fun trip down memory lane :) > > > > No one

Re: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly?

I agree that in general it is ok to cut a release with a partial solution in a case like this On Mon, Mar 5, 2018 at 8:40 AM andrea boriero wrote: > If there are no objections I can manage a release as soon as a fix is > ready. > > On 5 March 2018 at 14:20, Chris Cranford

Re: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises?

Fun trip down memory lane :) No one really like my proposed solution, but also no one really seemed to dislike it enough to implement something themselves ;) Anyway, those older discussions are a piece of the same overall discussion that this one belongs to. This discussion is just a specific

Re: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises?

+1 (a) is the only feasible option On Mon, Mar 5, 2018, 7:53 AM Sanne Grinovero wrote: > Issue HHH-12353 was just reported and I have to agree it looks dodgy. > > Essentially invoking: > > entityManager.getReference( Person.class ) > > might not return a type compatible

Re: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement

My personal feeling is that if the change itself is not going to make it into 5.3 then the SPI addition should not either. There are definitely 2 sides to this though. On the one hand, if you add this SPI method it will *without question* have to change for 6.0. In a way it is creating an

Re: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement

Honestly I am not sure about whether they are "related". I mean in 3949 the query sent to the database already does what you want it to do. I theory 3949 should be easier to fix. But what I find interesting there is that NO_PROXY is requested but it seems as if proxies are still used. On Fri,

Re: [hibernate-dev] 5.3 finalization plan

I have all of the caching and statistics changes done, however there are currently a few test failures because of the region-name issue. If I don't hear replies by Monday, I'll just pick a solution for that. Aka, speak now or forever hold your peace :) On Thu, Mar 1, 2018 at 1:37 PM Steve

Re: [hibernate-dev] Introduce OperationContext in 5.3?

I'm ok with it, but only if it's going to be ready in 2 weeks On Thu, Mar 1, 2018, 2:32 PM Gail Badner wrote: > Hi, > > HHH-10478 is currently scheduled for 6.0.0.alpha1. What do you think about > introducing it into 5.3.0 instead? > > Using an OperationContext would be a

[hibernate-dev] 5.3 finalization plan

In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified discussion about the remaining currently unresolved discussions and what exactly we are going to do for 5.3 mainly in regards to compatibility with an eye to 6.0 Cache region-name as exposed in API/SPI This one is a "sneaky"

Re: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ? [HHH-11253]

yet? > > Thanks, > Sanne > > > On 27 February 2018 at 11:13, Sanne Grinovero <sa...@hibernate.org> wrote: > > On 23 February 2018 at 20:29, Steve Ebersole <st...@hibernate.org> > wrote: > >> You mean change to 5.3? +1 > > > > Right tha

Re: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ? [HHH-11253]

You mean change to 5.3? +1 On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero wrote: > HHH-11253 is about making ByteBuddy the default implementation, but > it's flagged for 6. > > I think that in Paris there was consensus to make it the default in > 5.3 alredy, to possibly

Re: [hibernate-dev] Why does implicit join translate to inner join?

On Thu, Feb 22, 2018 at 9:11 AM Lukas Eder wrote: > Hi Steve, > > Thanks for your message. Of course, being explicit always has the > advantage of ... being explicit. But my question here is really about the > implicit join feature and how it works. > Sure, but that is

Re: [hibernate-dev] Why does implicit join translate to inner join?

Yes, this could be made sensitive to where the implicit join occurs. However, there is another, better way... explicit joins. In our opinion originally (and nothing has changed my mind about this) it is better to be consistent in how implicit joins are handled. It is far easier to impart to

Re: [hibernate-dev] Removing dom4j?

On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov wrote: > I think transitioning to automatic bindings via JAXB will result in error > messages on wrong configurations becoming far too vague to be useful to the > users. > I'm not understanding... we've used jaxb since 4.0 I am

Re: [hibernate-dev] Removing dom4j?

Would we be interested? Heck yeah. We have just not put in the effort because it is used for such a small subset of features *and* we plan to not use DOM/SAX directly moving forward (we are transitioning to JAXB). All that said though, I am surprised you ran into so few problems. Envers e.g.

Re: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3 and 6.0

Steve Ebersole <st...@hibernate.org> wrote: > I'm not sure what else to tell you. Sure some things have been removed. > > I'm not going to go through all of these right now. If there are some in > particular you are interested please bring those of specifically. > > >

Re: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3 and 6.0

incompatibilities. > > Am I missing something? Is there some other branch I should be comparing? > > Regards, > Gail > > On Thu, Feb 15, 2018 at 9:13 AM, Steve Ebersole <st...@hibernate.org> > wrote: > >> We have not integrated changes from master into 6.0 for a

[hibernate-dev] Hibernate ORM 5.3.0.CR1 released

First release fully passing the standalone JPA TCK. See http://in.relation.to/2018/02/15/hibernate-orm-530-cr1-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Starting 5.3 release

Actually I'll just rebase mine to the end. History will be wrong for a few commits, but it is what it is at this point On Thu, Feb 15, 2018 at 12:10 PM Steve Ebersole <st...@hibernate.org> wrote: > Well someone pushed. Now I'm going to have to force push. Grr > > > On Thu,

Re: [hibernate-dev] Starting 5.3 release

Well someone pushed. Now I'm going to have to force push. Grr On Thu, Feb 15, 2018 at 8:50 AM Steve Ebersole <st...@hibernate.org> wrote: > Per subject. Please do not push to master for the time being... > ___ hibernate-dev mailing li

Re: [hibernate-dev] API incompatibilities between Hibernate ORM 5.3 and 6.0

We have not integrated changes from master into 6.0 for a long time. And we probably won't for some time yet either. So comparisons between 5.2 or 5.3 and 6.0 right now are pointless On Wed, Feb 14, 2018 at 12:09 PM Gail Badner wrote: > I sent this last night with a huge

[hibernate-dev] Starting 5.3 release

Per subject. Please do not push to master for the time being... ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM 5.1 vs compatibility with Java 6

The only consistent way that is going to happen is to set it up on CI On Wed, Feb 14, 2018 at 8:27 AM Sanne Grinovero wrote: > Thanks for all feedback; I've opened: > - https://hibernate.atlassian.net/browse/HHH-12295 > > Please if you plan to make changes on branch 5.1

[hibernate-dev] 5.3.0 and JPA TCK

At this point, all of our challenges with Oracle over JPA TCK tests are resolved. Today I will be rerunning the ful TCK to verify that. Anyway, long story short unless there are objections I plan to make this version CR1 considering we've really just been waiting on the resolution of these

Re: [hibernate-dev] module org.hibernate.commons.annotations

+1 On Tue, Feb 13, 2018, 3:42 PM Sanne Grinovero wrote: > I'd like to release an Hibernate Commons Annotations version > 5.0.2.Final to declare its Jigsaw module name as an automatic module > name. Version 6 - whihch I proposed in a different thread - should > then use this

[hibernate-dev] Make JpaCompliance available earlier

I am working on HHH-12282. I was thinking that the best solution would be to check this setting at the time when Join#setOptional is called. The reason being to centralize the place that this check needs to be done. I can do it inside the persister as it consumes the Join, but that leads to

Re: [hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

Yes, I agree. On Sat, Feb 10, 2018, 7:55 AM Gunnar Morling <gun...@hibernate.org> wrote: > 2018-02-09 16:26 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > >> I think constraints should be exported to the DDL when the mode is DDL or >> `hibernate.validat

Re: [hibernate-dev] ORM DDL doesn't reflect BV constraints with validation mode CALLBACK

nd they wouldn't be added to the DDL if "hibernate > .validator.apply_to_ddl" is false or validation mode is NONE? > > That'd work for me. > > 2018-02-07 21:07 GMT+01:00 Steve Ebersole <st...@hibernate.org>: > >> No, I think you are right and `hibe

Re: [hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class

; > > On 01/31/2018 10:49 AM, Steve Ebersole wrote: > > Not to mention, I'm really not even sure what this request "means". As > > we all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory > > and Session/EntityManager, and that caused us to have

<    1   2   3   4   5   6   7   8   9   10   >