[hibernate-dev] [ORM] Support for upsert semantics
Hi, A common requirement that comes up repeatedly is "upsert" operations, i.e. either insert a record or update the existing one with the same PK, if it already exists. Many (most?) RDBMS support it, either by implementing SQL 2003's MERGE keyword or via proprietary alternatives [1]. I think it'd be great if there was something like Session#upsert(), exposing these semantics at the entity level. Perhaps the idea was already brought up in the past, but I wanted to throw it out in any case. Any thoughts? Cheers, --Gunnar [1] https://vladmihalcea.com/how-do-upsert-and-merge-work-in-oracle-sql-server-postgresql-and-mysql/ ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] NoORM IRC meeting minutes
Hi, Here are the minutes of this week's meeting: 15:18 < jbott> Meeting ended Tue Sep 11 13:18:04 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:18 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-11-13.00.html 15:18 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-11-13.00.txt 15:18 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-11-13.00.log.html Cheers, -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [ORM] Support for upsert semantics
It's been discussed several times in the past. We already have something very similar - `Session#saveOrUpdate`. So what exactly is the difference semantically? There really is none. There is, however, a practical difference... `Session#saveOrUpdate` handling leverages Hibernate's "unsaved value"[1] to decided between an INSERT and an UPDATE. In most cases, this is an extremely efficient decision. However, for an entity that (1) is unversioned and (2) uses assigned identifiers, Hibernate will actually perform a SELECT to make this decision. So it is conceivable to handle all `Session#saveOrUpdate` or maybe just this special case using an UPSERT. However, there are also cases where we simply cannot use UPSERT. The main one that comes to mind as particularly difficult is an entity which defines one or more properties (or sub-embedded properties) as insertable=true & updatable=false, or vice-versa. All-in-all I am just not convinced that the effort is worth it given the limited applicability. But certainly, if someone wanted to implement such a thing we should consider including it. Now, internally there is a case where we might be able to leverage UPSERTs for performance... Namely when updating an entity with optional secondary tables we will first try to update the row in the secondary table and then, if a row did not exist, insert one. We could change this to leverage UPSERT. However, we still have the same limitation with regard to insertable/updatable here as well. [1] HBM's `, don't think we have an annotation equivalent though at the moment. We have a pretty decent algorithm for "guessing" the unsaved value. On Tue, Sep 11, 2018 at 4:32 AM Gunnar Morling wrote: > Hi, > > A common requirement that comes up repeatedly is "upsert" operations, i.e. > either insert a record or update the existing one with the same PK, if it > already exists. Many (most?) RDBMS support it, either by implementing SQL > 2003's MERGE keyword or via proprietary alternatives [1]. > > I think it'd be great if there was something like Session#upsert(), > exposing these semantics at the entity level. Perhaps the idea was already > brought up in the past, but I wanted to throw it out in any case. > > Any thoughts? > > Cheers, > > --Gunnar > > [1] > > https://vladmihalcea.com/how-do-upsert-and-merge-work-in-oracle-sql-server-postgresql-and-mysql/ > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central
Strange. Any idea if this has anything to do with the maintenance done on Nexus? On Mon, Sep 10, 2018 at 6:15 AM, Yoann Rodiere wrote: > Thanks Guillaume, at least it's on someone else's plate now :) > > Yoann Rodière > Hibernate NoORM Team > yo...@hibernate.org > > > On Mon, 10 Sep 2018 at 14:43, Guillaume Smet > wrote: > > > On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere > > wrote: > > > >> I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should > >> report this issue to someone? Guillaume, maybe the same people you > >> reported > >> your Validator issue to? > >> > > > > I reported it in the issue I opened for HV a while ago. > > > > Don't hold your breath :). > > > > -- > > Guillaume > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
