[hibernate-dev] Test 2

___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives:

[hibernate-dev] Hibernate ORM 6.2.0 Final Release

Hibernate ORM 6.2.0 Final has just been released. See https://in.relation.to/2023/03/30/orm-62-final/ for the details. ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org

[hibernate-dev] Hibernate ORM 6.2.0.CR4 release

Hibernate ORM 6.2.0.CR4 has been released. See the announcement for the details. ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to

[hibernate-dev] Hibernate ORM 6.2 CR3 release

See the release announcement for the details. ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org

[hibernate-dev] Hibernate 6.2 CR2 release

This release has tons of bug fixes, stabilized code and support for SQL `MERGE`! Check it out - https://in.relation.to/2023/01/27/orm-62-cr2/ ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

Let me know what y'all think - https://github.com/hibernate/hibernate-orm/wiki/Huge-Project,-Small-Team On Thu, Jun 2, 2022 at 7:37 AM Steve Ebersole wrote: > I think we generally agree and understand each other here. > > > On Thu, Jun 2, 2022 at 6:32 AM Imre Jonk via h

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

I think we generally agree and understand each other here. On Thu, Jun 2, 2022 at 6:32 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > > This sounds a lot like how we do our version numbering as well. We try > to be as backward-compatible as possible with new "y"

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

Happened to be doing my morning email purge and this luckily came in at just that time :D On Wed, Jun 1, 2022 at 7:32 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > Hi Steve, > You can find our > support policy here if you are interested: >

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

On Tue, May 31, 2022 at 11:18 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > > I think the reality is that people who use software that has been > declared end-of-life by their suppliers often don't backport it > themselves. I've unfortunately seen enough cases of this

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

The reality is that we are a very small team - it is simply not feasible to maintain that many branches[1]. You are not asking about "time to upgrade" anyway, in my opinion. You are asking about removing the need to upgrade, which is very different. Us stopping support for 5.6 does not mean you

[hibernate-dev] Re: Hibernate ORM 5: end-of-life and upgrading

There is not a hard date. Not in the immediate future is the best I can say at the moment. On Mon, May 30, 2022 at 3:54 AM Imre Jonk via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > Hi there, > > We're very excited about the Hibernate ORM 6.0 release! Our developers > have looked

[hibernate-dev] Re: Hibernate ORM 6.0 Final

On Fri, Apr 1, 2022 at 3:34 AM Yoann Rodiere wrote: > Congratulations to you all! That's a huge milestone, after literal years > of work. > > Also, thanks for asking for opinions and helping with upgrades in Search > along the way, it really made keeping up with the Alphas/Betas/CRs easier. >

[hibernate-dev] Hibernate ORM 6.0 Final

Hibernate ORM 6.0 Final has been released - https://in.relation.to/2022/03/31/orm-60-final/ ___ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org

[hibernate-dev] SourceForge bundles

Per https://hibernate.atlassian.net/browse/HHH-14992 and https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/SourceForge.20bundles/near/265421351 I propose that we stop creating ZIP and TGZ bundles for upload to SourceForge. Creating those files and uploading them

[hibernate-dev] Re: Design of threadsafe, immutable internal components

Overall I generally agree and as far as I have ever heard using the concurrent form of hash-map rather than the non-concurrent one is a minimal overhead if at all, so why not. The way most of these Maps are used are already concurrency safe. So as long as we mean to simply keep this in mind when

[hibernate-dev] Re: HCANN evolution

On Thu, Oct 22, 2020 at 9:00 AM Sanne Grinovero wrote: > On Thu, 22 Oct 2020 at 14:50, Steve Ebersole wrote: > > N.B. I'm considering these steps as a preparation step, I didn't yet > address the core of the memory retention issue - I'll get to that > next, having simplified th

[hibernate-dev] Re: HCANN evolution

Sounds good, I'll take a look. Longer term, the best option from the perspective of ORM is to simply drop HCANN altogether in favor of Jandex + JAXB. In fact, I am considering playing with that on top of your work. It would be awesome to start dropping the things that hold us to including dom4j

[hibernate-dev] CI environment(s)

There is a discussion on https://github.com/hibernate/hibernate-orm/pull/3391 related to the use of Travis versus Jenkins for CI tests. If anyone has strong opinions please comment on the PR. Thanks! ___ hibernate-dev mailing list --

Re: [hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?

I also think ORM 6 is not the time to do this. Especially moving to Java 11. I think it is worthwhile though to discuss possibly moving to Java 9 to take advantage of multi-release jars as Christian mentioned. But Java 9 has its own set of difficulties for adoption with modules. It is a tough

Re: [hibernate-dev] [ORM] Query with condition on subclass attribute

It is not portable. Hibernate applies an implicit treat-as operation in such cases. This is actually Hibernate's behavior from the beginning. JPA says this should use an explicit treat-as operation. On Wed, Jul 1, 2020, 4:58 PM Gail Badner wrote: > Hi, > > Given the following inheritance

Re: [hibernate-dev] v6 and load-event

vide functionality like what we discussed for an > OperationContext? > > https://hibernate.atlassian.net/browse/HHH-10478 > > Thanks, > Gail > > On Fri, May 29, 2020 at 4:21 AM Steve Ebersole > wrote: > >> If/when it comes to needing that, I kind of like that c

Re: [hibernate-dev] My email

I started a discussion on the PR. Thanks Catalin On Wed, Jun 3, 2020 at 8:29 AM Catalin Tudose wrote: > Done. Please let me know if it is fine and if I should do anything else at > this point. > Thank you! > > On Wed, Jun 3, 2020 at 4:13 PM Steve Ebersole wrote: > >

Re: [hibernate-dev] My email

he source code for both examples (should I attach it to an > e-mail on the list?) and I hope it will worth your attention. > > On Wed, Jun 3, 2020 at 3:16 PM Steve Ebersole wrote: > >> Welcome! >> >> Depends if it is simply something that has not yet been implemented or

Re: [hibernate-dev] My email

Welcome! Depends if it is simply something that has not yet been implemented or if it truly is a bug. It is Alpha after all. Feel free to start a discussion here or on Zulip On Wed, Jun 3, 2020, 6:31 AM Sanne Grinovero wrote: > Sure that's not a problem. > > However, 6.x has many open issues

Re: [hibernate-dev] Hibernate Reactive: Release day!

Nice! Congratulations On Fri, May 29, 2020 at 9:27 AM Sanne Grinovero wrote: > It's released. Version 1.0.0.Alpha1 (not 0.0.1 as I mentioned in my > previous email) > > Kudos to Yoann, as it's fully automated and it takes just under a > minute to do the release - we should definitely try to do

Re: [hibernate-dev] v6 and load-event

Grinovero > wrote: > >> > >> Yes, I agree. > >> > >> On Thu, 28 May 2020, 22:11 Steve Ebersole, wrote: > >>> > >>> Wanted to clarify - > >>> > >>> Regarding incremental addition of "surround listeners&qu

Re: [hibernate-dev] v6 and load-event

Wanted to clarify - Regarding incremental addition of "surround listeners", so long as we are all in agreement that this simply means there will be absolutely no surround capability ***initially*** then I am fine with that. On Thu, May 28, 2020 at 4:10 PM Steve Ebersole wr

Re: [hibernate-dev] v6 and load-event

tantiation Regarding incremental addition of "surround listeners", so long as we are all in agreement that this simply means there will be absolutely no surround capability then I am fine with that. On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero wrote: > On Thu, 28 May 2020 a

Re: [hibernate-dev] v6 and load-event

Any thoughts on this "continuation" approach? Or maybe its just not important (yet) to handle "surround" handling? On Wed, May 27, 2020 at 9:27 AM Steve Ebersole wrote: > Inline... > > On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero > wrote: > >>

Re: [hibernate-dev] v6 and load-event

Inline... On Wed, May 27, 2020 at 8:10 AM Sanne Grinovero wrote: > At high level I agree, just have 3 more thoughts: > > # Regarding the "swap" of information between listeners - could that > even work? I might have misunderstood something, but wouldn't we > require listeners to run in some

Re: [hibernate-dev] v6 and load-event

ar : the signature I had >> to use is a bit puzzling, but it manages to avoid allocating the event >> (unless needed) and also avoids allocating the iterator on the >> listeners. >> >> For example PostLoad events by default have a single listener, but >> looking mor

Re: [hibernate-dev] Beyond checkstyle

It is an interesting idea. Guess it depends just how configurable it is to get what we want. On Tue, May 26, 2020 at 5:03 AM Sanne Grinovero wrote: > Hi all, > > in Quarkus we're using a plugin which automatically reformats the code > and sorts imports. > > In our older projects we've been

[hibernate-dev] v6 and load-event

Historically we made a terrible design mistake with the event system as a whole. This has both a confusing design impact and a very real performance impact. The main problem is the smashing together of things that handle events and things that listen to such events. In working on a problem in

[hibernate-dev] ORM 6.0 Alpha5 released

https://in.relation.to/2020/04/24/hibernate-orm-600-Alpha5-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Unable to release :(

I manually uploaded to SourceForge and Andrea helped (thanks!) with the doc server. I'll work on a release announcement this weekend, there was a lot involved in this one. On Fri, Apr 24, 2020 at 2:11 PM Steve Ebersole wrote: > I ran the 6.0 Alpha5 release. All the tasks completed f

[hibernate-dev] Unable to release :(

I ran the 6.0 Alpha5 release. All the tasks completed fine except I was not able to upload the "dist" to Sourceforge nor the docs to JBoss. All artifacts are pushed to BinTray. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org

Re: [hibernate-dev] Migration to Jakarta API: some practical aspects in dealing with Git and mass replacements

Thanks for taking care of this Sanne. On Mon, Apr 20, 2020 at 7:58 AM Sanne Grinovero wrote: > Hi all, > > the migration to the Jakarta API is rather simple and can be performed > by "find and replace" operations, but it will affect a lot of code and > might get int the way of other work. > >

Re: [hibernate-dev] HHH-13916 / WFLY-13259

Not really sure what "better" names you have in mind, but to me only one of these 2 is really an identifier. This new method is more a niche value to me. So not sure why you want to rename the original. On Fri, Apr 17, 2020 at 3:36 PM Sanne Grinovero wrote: > On Thu, 16 Apr 2020 at 01:06,

Re: [hibernate-dev] Hibernate Rx: Remove Optional from API

Bit off track, but since you mentioned load, etc... Take a look at the IdentifierLoadAccess, etc variants for loading. E.g. interface IdentifierLoadAccess { T getReference(Object id); T load(Object id); Optional loadOptional(Object id); } Granted I'm partial, but I think that's

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

owse/HHH-13951 > > Yoann, great idea about the platform agnostic testrunner. We should > keep that in mind, hopefully we'll be able to make it happen > eventually. > > Thanks, > Sanne > > > On Thu, 16 Apr 2020 at 13:46, Steve Ebersole wrote: > > > > Consi

Re: [hibernate-dev] Remove or disable the WildFly feature packs of Hibernate ORM?

Considering the changes in WildFly, I also think we should just drop hibernate-orm-modules. For 6.0 I will definitely do this. I also think removing it is good for 5.5. Not sure it is even worth the hassle for earlier releases however. On Wed, Apr 15, 2020 at 5:03 PM Sanne Grinovero wrote:

[hibernate-dev] ORM 6 : hibernate-orm-modules & Antlr 4

I am working on re-enabling the `hibernate-orm-modules` module but am running into a problem being able to resolve Antlr 4 classes. I'm sure the problem is related to the entry `` in `hibernate-core.xml` but I am not sure how to fix that. Any ideas?

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

When y'all talk about the bytecode enhancement solution, I'd like to better understand what you mean exactly. Do you mean at run-time like we did for ORM when we combined Session/EntityManager? The problem there is that this only works when we control the environment (WildFly e.g.). Do you mean

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

I'm curious... why are we saying that we need to simultaneously support both sets of annotations and config settings? As a user, if I choose to use the Jakarta-based JPA I would fully expect that to only work with the Jakarta-based annotations and settings. Is there something in the spec I am

Re: [hibernate-dev] Custom EventType and listeners

I agree at the high level. On Thu, Mar 5, 2020 at 9:17 AM Sanne Grinovero wrote: > Hi Gail, > > at high level it seems a reasonable idea to me. > > In more detail, let's make sure the `registeredEventListeners` > initialization is not affected by data races, but we can defer > discussing such

Re: [hibernate-dev] Property using field access and has final getter/setter method

If any getters or setters are final then the ProxyFactory cannot be used and imo should not get built, especially moving forward as we could use bytecode-based proxies On Wed, Mar 4, 2020 at 2:11 PM Gail Badner wrote: > This commit [1] for HHH-11838 [2] causes an error to get logged by >

Re: [hibernate-dev] Hibernate ORM : format of the version logged on boot

I tend to agree with Gail here. Sure Sanne I understand your view there, but realistically: 1) which other ORM jars do you see printing its version? 2) when are you expecting that ORM jar versions can be mixed amongst the different modules? On Thu, Feb 13, 2020 at 10:42 AM Sanne Grinovero

Re: [hibernate-dev] 6.0 - HQL literals

Hi Dave. Same - I was swamped with stuff at the end of last week. Yes, from what I was reading postgres is a bit strange in storing temporal values. Not unique to postgres - many databases do interesting things. I'm curious how the driver handles binding Java 8 types directly. The JDBC spec

Re: [hibernate-dev] 6.0 - HQL literals

b6d27bf61fc8a93443/util/common/src/main/java/org/hibernate/search/util/common/impl/TimeHelper.java#L38 > > > I think the confusion here is in terms of (1) recognizing a temporal > literal and "parsing it" and (2) applying it to SQL. Different parts of > the puzzle. &

Re: [hibernate-dev] 6.0 - HQL literals

Well, again, this is configurable. If you don't want to use it, don't ;) On Thu, Jan 9, 2020 at 1:28 AM Christian Beikov wrote: > Am 08.01.2020 um 20:21 schrieb Steve Ebersole: > > On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov < > christian.bei...@gmail.com> wrote: > &g

Re: [hibernate-dev] 6.0 - HQL literals

On Wed, Jan 8, 2020 at 9:22 AM Christian Beikov wrote: > > This is about JPA Criteria whereas I was referring to how a literal in > HQL ends up in the SQL. I agree that with JPA Criteria things are > different as the API for parameters in queries is not very neat. A flag > for controlling how

Re: [hibernate-dev] 6.0 - HQL literals

On Wed, Jan 8, 2020 at 7:11 AM Christian Beikov wrote: > Am 08.01.2020 um 13:50 schrieb Steve Ebersole: > > On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov > > mailto:christian.bei...@gmail.com>> wrote: > > > > If a user enters a HQL lit

Re: [hibernate-dev] 6.0 - HQL literals

On Wed, Jan 8, 2020 at 6:09 AM Christian Beikov wrote: > If a user enters a HQL literal, that user wants the literal to be > rendered like that if possible(which should always be possible). > Like I said earlier, we actually try to render literals (of any type) as parameters whenever we can

Re: [hibernate-dev] 6.0 - HQL literals

gt; > > > > Note that a bug affects parsing ZoneDateTimes with both offset and zone > > ID > > > on JDK8 (fixed in 9): https://bugs.openjdk.java.net/browse/JDK-8066982 > > > We have a helper to work around that in Search: > > > > > > > > > http

Re: [hibernate-dev] 6.0 - HQL literals

On Wed, Jan 8, 2020 at 4:21 AM Yoann Rodiere wrote: > > This does nothing with Type. The way the grammar is defined it > literally understands each piece of the temporal. So given, e.g., > {2020-01-01}, we know that 2020 is the year, etc. This is the benefit of > defining it syntactically. >

Re: [hibernate-dev] 6.0 - HQL literals

> > As far as I know, even Java does not support that. A true zone-id would > be something like (for me) "America/Chicago". If I ask Java to parse > "2020-01-01 10:10:10 America/Chicago +02:00" it just says no. For me, CST > (standard) and CDT (daylight savings) are really synonyms for offset -

Re: [hibernate-dev] 6.0 - HQL literals

On Tue, Jan 7, 2020 at 10:05 AM Yoann Rodiere wrote: > On Tue, 7 Jan 2020 at 14:45, Steve Ebersole wrote: > >> Sorry, I should have been more clear. The literals are not "passed >> through"; it's just a mechanism to be able to recognize the literal >> syntacti

Re: [hibernate-dev] 6.0 - HQL literals

Thanks for the feedback. I added some comments in-line. On Tue, Jan 7, 2020 at 1:59 AM Yoann Rodiere wrote: > Hi, > > The syntax looks nice. > I suppose it's future-proof enough, though I can imagine us getting in > trouble if JDBC starts allowing parameterized or custom formats, which may >

[hibernate-dev] 6.0 - HQL literals

Initially when I started working on 6.0 I added support for defining temporal literals using JDBC's "escape syntax". JDBC already defines a syntax for declaring temporal literals using this syntax - - {d '2020-01-01'} for a Date - {t '10:10:10'} for a Time - {ts '2020-01-01 10:10:10'}

Re: [hibernate-dev] Composite IDs with a null property/field

I've already chimed in ;) I don't think this is something we should do. On Wed, Dec 18, 2019, 3:44 PM Gail Badner wrote: > The main obstacle I see is that Hibernate assumes that ID columns are > non-nullable, even if ID columns are explicitly mapped as nullable. > > This is consistent with

Re: [hibernate-dev] IdClass superclasses

Actually I was thinking of @EmbeddedId, but you were asking about @IdClass. I think (2) sounds more natural. On Tue, Dec 10, 2019 at 3:12 PM Steve Ebersole wrote: > To me this is perfectly consistent with how inheritance works in entity > hierarchies. Unless a super type is

Re: [hibernate-dev] IdClass superclasses

To me this is perfectly consistent with how inheritance works in entity hierarchies. Unless a super type is marked with @Entity or @MappedSuperclass, the "attributes" defined on that specific class are not picked up. Maybe I'm misunderstanding you? On Mon, Dec 9, 2019 at 1:58 PM Gail Badner

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

> > > JPA does not allow mixing of @IdClass and @EmbeddedId. But I think > that's a valid option. In fact in our original work on 6 where we > completely replaced the mapping model (persisters) i had added support for > this. We could add an improvement to pull this feature to 6 proper? > >

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

name="FK2", referencedColumnName="lastName") }) @ManyToOne Employee emp; ... } It would be nice to allow loading a Dependent like: `session.load( Dependent.class, new Object[] {"Steve","Ebersole"} );` The trouble there is the ordering of the values compared

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

I think Sanne meant relying on equals/hasCode of the embeddable itself, which we do not do as you pointed out. On Wed, Dec 4, 2019 at 5:19 PM Gail Badner wrote: > Hi Sanne, > > By default, the cache key is of type CacheKeyImplementation [1]. As long as > a composite key is a ComponentType (not

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

This all sounds s familar. But I was not able to find the Jira. Seems to be there was a reason that we don't disassemble the id, though that reason escapes me atm. That does seem like the logical thing to do. Regardless of why I think we may have decided not to, it would still be

[hibernate-dev] ORM 6.0.0 Alpha3 released

The third Alpha of ORM 6.0 has just been released. See the details at https://in.relation.to/2019/11/24/600-Alpha3-release/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Planning next 6.0 Alpha

Andrea and I talked this morning about where we are with 6.0 development and planning the next Alpha as well as moving the work branch back upstream. Next week we will see how far we are on the tasks we are currently working on. The triggers for the release/move are: 1. WRT inheritance,

Re: [hibernate-dev] "JDK: oraclejdk8 Java" check is failing for a PR

Nice! On Tue, Oct 15, 2019, 5:57 PM Gail Badner wrote: > It passed this time. :) > > On Tue, Oct 15, 2019 at 2:51 PM Gail Badner wrote: > >> OK, I see it now. >> >> Thanks! >> Gail >> >> On Tue, Oct 15, 2019 at 2:24 PM Steve Ebersole >

Re: [hibernate-dev] "JDK: oraclejdk8 Java" check is failing for a PR

Yes, in the upper right end corner there is a "Restart Job" link... That's for any Travis job On Tue, Oct 15, 2019 at 1:20 PM Gail Badner wrote: > "JDK: oraclejdk8 Java" check is failing [1] for PR: > https://github.com/hibernate/hibernate-orm/pull/3066 > > It's showing that

Re: [hibernate-dev] Rebased ORM6

We went ahead and finished the remaining merges and pushed to https://github.com/sebersole/hibernate-core/tree/wip/6.0 To be clear - this branch includes everything from master (as of this morning) and all ongoing 6.0 work. On Wed, Sep 4, 2019 at 8:08 AM Steve Ebersole wrote: > Andrea an

Re: [hibernate-dev] Rebased ORM6

Andrea and I took a look at this `SessionImpl#buildLockOptions` as you asked. But unfortunately your work moved the logic completely around, moving it from a no-longer-existent method into a static method on a new helper class you added. So its hard to compare what functionally changed. On

Re: [hibernate-dev] EntityMetamodel

Seems like we dropped the need for the subclass checking here but did not remove passing that Function. Technically it could be removed and the EntityMetamodel constructor reverted On Mon, Sep 2, 2019 at 9:14 PM Gail Badner wrote: > HHH-11147 changed a EntityMetamodel constructor argument from

Re: [hibernate-dev] Property#isLazy

Do you have an example where this is actually a problem? On Mon, Sep 2, 2019 at 8:01 PM Gail Badner wrote: > HHH-11147 changed Property#isLazy as shown in [1]. > > The part that concerns me is: > > + // For a many-to-one, this is always false. Whether the > + // association is EAGER, PROXY or

Re: [hibernate-dev] No default implementation for PersistenceContext#addEnhancedProxy

We do not support an application implementing a custom PersistenceContext. I'm not against adding a default, but most likely that default would be a "throw an exception" type which I am not sure is useful On Mon, Sep 2, 2019 at 4:19 PM Gail Badner wrote: > HHH-11147 added

Re: [hibernate-dev] hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo

In my opinion we really should not drop them unless we also write a conversion for the existing I'd values in the database to account for the new scheme the user picks. It's really just left there to allow these legacy databases keep working On Wed, Aug 28, 2019 at 7:09 AM Steve Ebersole wrote

Re: [hibernate-dev] Entity implementation of equals()

ere is still an issue though when comparing to a HibernateProxy. > > This returns false: bID.equals( that.bID). > > This returns true: bID.equals( that.getbID() ). > > I've never noticed this before. > > Steve, is there some requirement that getters have be used to compare > pr

Re: [hibernate-dev] Entity implementation of equals()

Generally speaking an `#equals` method would not allow subclasses to match. For entity mappings specifically I this it is generally considered kosher to allow subclass matching in `#equals`. Interestingly, when generating `#equals` overrides through IntelliJ it even asks specifically whether

Re: [hibernate-dev] ConnectionObserver

I'm fine with deprecating and removing. WRT changing `List` to just `ConnectionObserver` rather we'd want to change it to `ConnectionObserverStatsBridge` to avoid the polymorphic call overhead. But otherwise I agree with everything On Tue, Aug 20, 2019 at 3:51 PM Gail Badner wrote: > In 4.2

Re: [hibernate-dev] Any external uses for ORM's StatisticsImpl ?

I do not remember the history for it. +1 for removing that no-arg form. On Wed, Aug 7, 2019 at 4:08 AM Sanne Grinovero wrote: > Hi all, > > while working on HHH-13527 I noticed that there's quite some > complexity in StatisticsImpl to deal with the fact that the final > field `sessionFactory`

Re: [hibernate-dev] Test FormulaWithPartitionByTest seems to rely on implementation specific ordering

The query is selecting ids, so I assume you mean `1,2,3` as the expectation. Clearly Firebird cannot support what the query is attempting to do - so the best option is to skip this test for Firebird. However, the order-by is really not serving any purpose to the test aside from making the

Re: [hibernate-dev] Post-connect queries for 6.1?

Add a feature request to Jira I guess. Of course you can already achieve this using a custom ConnectionProvider and most connection pools allow such things. For me personally this is not a critical feature. On Mon, May 13, 2019 at 7:57 AM Jordan Gigov wrote: > I thought it would be good to

[hibernate-dev] HHH-11147 - bytecode based "proxies"

Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which essentially allows bytecode enhancement to behave like the more traditional proxy feature (create a reference based solely on the entity id). We are wrapping up development of that improvement, enhancement, change,

Re: [hibernate-dev] Jenkins upgrade

Thanks guys! On Tue, Apr 30, 2019 at 8:07 AM Davide D'Alto wrote: > On a related note, I've created a new AMI to use as slave and > configure Jenkins to use it. > If there are issues, it is still possible to use the old one by > updating the Jenkins configuration

Re: [hibernate-dev] [ORM] Do we have a way to check if an object is an entity?

stenceProviderResolver(); List providers = resolver.getPersistenceProviders(); On Thu, Apr 25, 2019 at 1:25 PM Guillaume Smet wrote: > On Thu, Apr 25, 2019 at 8:05 PM Steve Ebersole > wrote: > >> EMF + Metamodel are standard JPA contracts: >> >> >> try { &

Re: [hibernate-dev] [ORM] Do we have a way to check if an object is an entity?

EMF + Metamodel are standard JPA contracts: try { emf.getMetamodel().managedType( theClass ); } catch ( IllegalArgumentException e ) { // JPA defined exception if the passed class is not a managed type } Again, that will (should) work on any provider On Thu, Apr 25, 2019 at

Re: [hibernate-dev] Make Gradle plugin available on plugins.gradle.org? (HHH-13354)

It would need to be published differently than the rest of the modules (or an extra additional publish). It is a good idea though On Tue, Apr 9, 2019 at 9:15 AM Sanne Grinovero wrote: > Hi Gail, > > I'm familiar with the Gradle plugin portal, happy to look into this. > Thanks for highlighting

Re: [hibernate-dev] 6.0 - multi-table mutations

On Tue, Mar 26, 2019 at 10:17 AM Sanne Grinovero wrote: > > Why should we not? > There is a very compelling reason for that. I'll have to leave it at that. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org

Re: [hibernate-dev] 6.0 - multi-table mutations

On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote: > One question: could we benefit from "cascade delete" rules defined in > the table structure? > If Hibernate ORM was able parse the cascading rules from existing > schemas, and possibly generate them for new schemas, you could have an >

Re: [hibernate-dev] 6.0 - multi-table mutations

https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/6.2E0.20-.20multi-table.20mutation On Tue, Mar 26, 2019 at 8:25 AM Steve Ebersole wrote: > While working on 6 I discovered that we maybe do not do the best job in > regards to "bulk update/delete"

[hibernate-dev] 6.0 - multi-table mutations

While working on 6 I discovered that we maybe do not do the best job in regards to "bulk update/delete" queries against multi-table entities (secondary tables, joined inheritance, etc). This short-coming exists in previous versions. Essentially, when a strategy is not explicitly specified we

Re: [hibernate-dev] Should we support out of date non-LTS Java versions?

+1 to everything Yoann said. On Wed, Feb 13, 2019, 5:42 AM Yoann Rodiere wrote: > Hi, > > I think we should make it clear that only LTS JVMs are actually supported, > and non-LTS JVMs are only supported on a "best effort" basis, with some > focus on the very latest non-LTS JVM. > I doubt we

Re: [hibernate-dev] Still an issue with Agroal when closing the pool

Have we gotten any reply about this? On Wed, Jan 23, 2019 at 8:58 AM Guillaume Smet wrote: > Hello Luis, > > Any chance you could take a look at this one? > > I just got it again on my laptop and it happened quite frequently on our CI > lately. > > AFAICS, it's always failing in the setting

Re: [hibernate-dev] Loggers

want TRACE/DEBUG logging to potentially be messaged (with id) logs? On Fri, Sep 28, 2018 at 10:46 AM Sanne Grinovero wrote: > On Fri, 28 Sep 2018 at 16:43, Steve Ebersole wrote: > > > > Thanks for the feedback! > > I'm actually sorry for the delay :) Just back from 2 we

Re: [hibernate-dev] [ORM] Reducing startup log verbosity

Sounds good to me! :) On Fri, Jan 11, 2019 at 8:19 AM Sanne Grinovero wrote: > On Fri, 11 Jan 2019 at 14:00, Steve Ebersole wrote: > > > > Guillaume - I added a general start-a-discussion comment to the PR. > Hopefully anyone with an opinion on that can chime in there.

Re: [hibernate-dev] [ORM] Reducing startup log verbosity

Guillaume - I added a general start-a-discussion comment to the PR. Hopefully anyone with an opinion on that can chime in there. Beyond that, +1 Sanne - ok, I see. You are not expecting users to have to deal with wrapping/scrolling because you limit the presented information to an arbitrary

Re: [hibernate-dev] Default access type and MappedSuperclass

Trying to make sure I understand.. so the report is just wrong? Or is there some difference in your model versus theirs? On Thu, Jan 10, 2019 at 2:22 PM andrea boriero wrote: > yes also for the MappedSuperclass > > from: > > @MappedSuperclass > public abstract class AbstractCatalogEntity { >

Re: [hibernate-dev] [ORM] Reducing startup log verbosity

On Thu, Jan 10, 2019 at 10:15 AM Sanne Grinovero wrote: > On Thu, 10 Jan 2019 at 01:44, Steve Ebersole wrote: > > > > I disagree that logging a single message is a better solution because > that probably ends up wrapping multiple lines, just as your sample happened > to

Re: [hibernate-dev] Default access type and MappedSuperclass

ingOver%28%29 Disclaimer - I have not tried this, just read about it... On Thu, Jan 10, 2019 at 7:18 AM Steve Ebersole wrote: > This is one of the cases (there are others) where we do not completely > follow the JPA spec. > > TBH I'm not really sure how we would address this in an

Re: [hibernate-dev] Default access type and MappedSuperclass

This is one of the cases (there are others) where we do not completely follow the JPA spec. TBH I'm not really sure how we would address this in an annotation processor, though granted my knowledge of those APIs is limited. But as I understand it we have to generate the metamodel class as we

  1   2   3   4   5   6   7   8   9   10   >