[hibernate-dev] Question about current flush ordering
Hi, There is this issue that has puzzled me for many years related to ActionQueue ordering: - OrphanRemovalAction.class, - AbstractEntityInsertAction.class, - EntityUpdateAction.class, - QueuedOperationCollectionAction.class, - CollectionRemoveAction.class, - CollectionUpdateAction.class, - CollectionRecreateAction.class, - EntityDeleteAction.class, Why is it that we execute the OrphanRemovalAction firsts, but the EntityDeleteAction last? Shouldn't the EntityDeleteAction be executed before Insert or Update? There musts be a reason for choosing this ordering, but I can't figure out why the EntityDeleteAction was chosen to be executed last. Vlad ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Question about current flush ordering
On 28 March 2017 at 10:03, Vlad Mihalcea wrote: > There musts be a reason for choosing this ordering, but I can't figure out > why the EntityDeleteAction was chosen to be executed last. > Isn't it simply to avoid foreign key constraints to explode? When you update a reference to a foreign key *and* delete the previous target of this reference in the same transaction, you want to execute the update first and the delete last. I can't imagine why orphan removals are executed first, though. Yoann Rodière Hibernate NoORM Team ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [OGM] Hibernat OGM contrib repository
Hi all, I've moved the contributed dialect for OGM in this repository: https://github.com/DavideD/hibernate-ogm-contrib I have a couple of quesitons before moving it in an official repository: - Which group id should we use? At the moment it is still org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib - What about the license? Can I re-use the same in Hibernate OGM? I still need to update the README, this is the related PR for OGM: https://github.com/hibernate/hibernate-ogm/pull/850 Thanks, Davide ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Hibernat OGM contrib repository
Hi, I've moved the contributed dialect for OGM in this repository: > https://github.com/DavideD/hibernate-ogm-contrib Great, thanks :) Which group id should we use? At the moment it is still > org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib > +1 for org.hibernate.ogm.contrib. I would say let's use a different group ID when the release cycles are different. Which is the case here. What about the license? Can I re-use the same in Hibernate OGM? I would say you will *have* to use the same, or a compatible one, unless you want to ask permission to every single past contributor (which I think is required to re-license a codebase)... Yoann Rodière Hibernate NoORM Team On 28 March 2017 at 12:28, Davide D'Alto wrote: > Hi all, > I've moved the contributed dialect for OGM in this repository: > https://github.com/DavideD/hibernate-ogm-contrib > > I have a couple of quesitons before moving it in an official repository: > > - Which group id should we use? At the moment it is still > org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib > > - What about the license? Can I re-use the same in Hibernate OGM? > > I still need to update the README, this is the related PR for OGM: > https://github.com/hibernate/hibernate-ogm/pull/850 > > Thanks, > Davide > ___ > 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] [OGM] Hibernat OGM contrib repository
Regarding the License I think we have no choice, we have to use the same license as alternatively we'd need to get permission to change the license as it's existing code. I'm assuming we have no interest in that, and if we had this process would take some time so we'd have to propose such a change as an independent step from the repository move. Regarding group-id : I see no reason to change it but have no strong opinion on that. I'd similarly suggest to make such changes as a follow-up though, and not treat it as a blocker. (If we decide to change it, it would be a breaking change so we'd need redirection poms so we might as well do it later) Thanks, Sanne On 28 March 2017 at 11:28, Davide D'Alto wrote: > Hi all, > I've moved the contributed dialect for OGM in this repository: > https://github.com/DavideD/hibernate-ogm-contrib > > I have a couple of quesitons before moving it in an official repository: > > - Which group id should we use? At the moment it is still > org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib > > - What about the license? Can I re-use the same in Hibernate OGM? > > I still need to update the README, this is the related PR for OGM: > https://github.com/hibernate/hibernate-ogm/pull/850 > > Thanks, > Davide > ___ > 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] 6.0 - id type
+1, as proposed a long time ago :) On 28 March 2017 at 07:52, Vlad Mihalcea wrote: > +1 > > I remember that Spring Data CRUDRepository has this restriction that ID > extends Serializable just because Hibernate required it so. I agree that we > should drop this restriction and allow non-Serializable @Id as other JPA > providers. > > On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov < > christian.bei...@gmail.com> wrote: > >> +1 for that. Stumbled over that once or twice in the past and wondered >> what the reasons were. >> >> >> Mit freundlichen Grüßen, >> >> *Christian Beikov* >> Am 27.03.2017 um 19:37 schrieb Steve Ebersole: >> > In all versions of Hibernate to-date we have required that the Java type >> of >> > an id be Serializable. Strictly speaking JPA has no such restriction - >> it >> > says ids can be any Object type *unless* the entity is to be serialized, >> in >> > which case the id must be Serializable (duh). >> > >> > As we transition into 6.0, I wonder if we want to loosen this restriction >> > and allow the id to be any Object type as well. There really is no valid >> > reason (beyond the obvious case explicitly discussed in the JPA spec) for >> > requiring the id to be Serializable. >> > >> > WDYT? >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - id type
We've all "proposed" it at some point Sanne ;) The bigger question is when to do it since it means API changes. But it sounds like everyone is on board for that for 6.0 On Tue, Mar 28, 2017, 6:54 AM Sanne Grinovero wrote: > +1, as proposed a long time ago :) > > On 28 March 2017 at 07:52, Vlad Mihalcea wrote: > > +1 > > > > I remember that Spring Data CRUDRepository has this restriction that ID > > extends Serializable just because Hibernate required it so. I agree that > we > > should drop this restriction and allow non-Serializable @Id as other JPA > > providers. > > > > On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov < > > christian.bei...@gmail.com> wrote: > > > >> +1 for that. Stumbled over that once or twice in the past and wondered > >> what the reasons were. > >> > >> > >> Mit freundlichen Grüßen, > >> > >> *Christian Beikov* > >> Am 27.03.2017 um 19:37 schrieb Steve Ebersole: > >> > In all versions of Hibernate to-date we have required that the Java > type > >> of > >> > an id be Serializable. Strictly speaking JPA has no such restriction > - > >> it > >> > says ids can be any Object type *unless* the entity is to be > serialized, > >> in > >> > which case the id must be Serializable (duh). > >> > > >> > As we transition into 6.0, I wonder if we want to loosen this > restriction > >> > and allow the id to be any Object type as well. There really is no > valid > >> > reason (beyond the obvious case explicitly discussed in the JPA spec) > for > >> > requiring the id to be Serializable. > >> > > >> > WDYT? > >> > ___ > >> > hibernate-dev mailing list > >> > hibernate-dev@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] NoORM IRC meeting minutes
Hi, Spring is here and so are the minutes of this week's NoORM IRC meeting: 16:06 < jbott> Meeting ended Tue Mar 28 14:06:02 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 16:06 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.html 16:06 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.txt 16:06 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.log.html Have a nice day! -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
Hi, Would it be possible for a WildFly deployment unit processor to detect Hibernate ORM native applications, by detecting the presence of a particular configuration file that is always present? I'm not sure if this is possible, but if it is, perhaps WildFly could automatically add the (supported) Hibernate orm module to the native application, if the deployment is clearly marked as a Hibernate native application, as well as also exporting Javassist to the deployment. Thoughts? Scott On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow wrote: >>> Right, Hibernate ORM's module should be the one exposing it, not the >>> application nor JipiJapa. >> >> JipiJapa has zero to do with this, we will create a pr later today to >> remove the unneeded dependencies, which has nothing to do with this >> conversation. > > https://github.com/wildfly/wildfly/pull/9305 is for removing the > unused Javassist dependency from JipiJapa. Also removed a few other > unused dependencies. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
On 03/28/2017 11:30 AM, Scott Marlow wrote: > Hi, > > Would it be possible for a WildFly deployment unit processor to detect > Hibernate ORM native applications, by detecting the presence of a > particular configuration file that is always present? I'm not sure if > this is possible, but if it is, perhaps WildFly could automatically > add the (supported) Hibernate orm module to the native application, if > the deployment is clearly marked as a Hibernate native application, as > well as also exporting Javassist to the deployment. A related question, is there a standard Hibernate annotation class that native Hibernate applications always use that we could scan for the same reasons, as an alternative to scanning for Hibernate configuration files? > > Thoughts? > > Scott > > > > On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow wrote: Right, Hibernate ORM's module should be the one exposing it, not the application nor JipiJapa. >>> JipiJapa has zero to do with this, we will create a pr later today to >>> remove the unneeded dependencies, which has nothing to do with this >>> conversation. >> https://github.com/wildfly/wildfly/pull/9305 is for removing the >> unused Javassist dependency from JipiJapa. Also removed a few other >> unused dependencies. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly
Hi Scott, no I don't think that's possible. There are many ways of bootstrapping Hibernate, and "using code" is also a valid option, which implies end users have the option to read configuration properties from custom sources or even hard-code configuration. Granted in practice they'll likely use Spring or other frameworks to boot it, but a list of such frameworks would necessarily be open-ended. Not least, I wouldn't want you to automatically add Hibernate ORM dependencies as it's very likely in most of these cases that the end user will want to use a different version of Hibernate ORM to match the requirements of the framework do jour, or otherwise include a custom version. The only "safe default" would be to inspect the bytecode of the deployment and see if both conditions are true: - any class refers to Hibernate (JPA) code / annotations - no Hibernate version is included On top of this not being simple to perform, it would also not be a safe operation as Hibernate evolves so you can't really be sure if some future version has not been included. I'd highly prefer the simplicity of WildFly behaving without any complex guess work: inject Hibernate when asked for it. Doing this based on the META-INF/persistence.xml presence seems a reasonable compromise but anything more complex is something that people will have to understand to control it.. Thanks, Sanne On 28 March 2017 at 16:46, Scott Marlow wrote: > > > On 03/28/2017 11:30 AM, Scott Marlow wrote: >> Hi, >> >> Would it be possible for a WildFly deployment unit processor to detect >> Hibernate ORM native applications, by detecting the presence of a >> particular configuration file that is always present? I'm not sure if >> this is possible, but if it is, perhaps WildFly could automatically >> add the (supported) Hibernate orm module to the native application, if >> the deployment is clearly marked as a Hibernate native application, as >> well as also exporting Javassist to the deployment. > > A related question, is there a standard Hibernate annotation class that > native Hibernate applications always use that we could scan for the same > reasons, as an alternative to scanning for Hibernate configuration files? > >> >> Thoughts? >> >> Scott >> >> >> >> On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow wrote: > Right, Hibernate ORM's module should be the one exposing it, not the > application nor JipiJapa. JipiJapa has zero to do with this, we will create a pr later today to remove the unneeded dependencies, which has nothing to do with this conversation. >>> https://github.com/wildfly/wildfly/pull/9305 is for removing the >>> unused Javassist dependency from JipiJapa. Also removed a few other >>> unused dependencies. > > ___ > 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] Javassist dependency conflict in the ORM modules for WildFly
On 28 March 2017 at 17:28, Steve Ebersole wrote: > > > On Tue, Mar 28, 2017 at 11:12 AM Sanne Grinovero > wrote: >> >> Hi Scott, >> >> no I don't think that's possible. There are many ways of bootstrapping >> Hibernate, and "using code" is also a valid option, which implies end >> users have the option to read configuration properties from custom >> sources or even hard-code configuration. >> >> Granted in practice they'll likely use Spring or other frameworks to >> boot it, but a list of such frameworks would necessarily be >> open-ended. >> >> Not least, I wouldn't want you to automatically add Hibernate ORM >> dependencies as it's very likely in most of these cases that the end >> user will want to use a different version of Hibernate ORM to match >> the requirements of the framework do jour, or otherwise include a >> custom version. >> >> The only "safe default" would be to inspect the bytecode of the >> deployment and see if both conditions are true: >> - any class refers to Hibernate (JPA) code / annotations >> - no Hibernate version is included > > > You mean strictly in terms of whether to inject Hibernate dependencies I > guess. Because this does not give Scott what he asked for. As I mentioned > to Scott on HipChat, the only possible "auto" choice I can see is whether > the app includes a persistence.xml, but even that can be inaccurate. > > So ultimately I think there should also be a deployment flag to be the > definitive answer to whether we should "inject Hibernate" because the user > "asked for it". +1 Above I'm just trying to describe why any other alternative is not safe. Not least, any reasonable user will prefer a configuration line over some unclear, automagic strategy. I'd highly prefer consistency, especially when it comes to dependencies I'll have on classpath. Thanks, Sanne ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - id type
+1 for 6.0 On 03/28/2017 08:33 AM, Steve Ebersole wrote: > We've all "proposed" it at some point Sanne ;) The bigger question is when > to do it since it means API changes. > > But it sounds like everyone is on board for that for 6.0 > > On Tue, Mar 28, 2017, 6:54 AM Sanne Grinovero wrote: > >> +1, as proposed a long time ago :) >> >> On 28 March 2017 at 07:52, Vlad Mihalcea wrote: >>> +1 >>> >>> I remember that Spring Data CRUDRepository has this restriction that ID >>> extends Serializable just because Hibernate required it so. I agree that >> we >>> should drop this restriction and allow non-Serializable @Id as other JPA >>> providers. >>> >>> On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov < >>> christian.bei...@gmail.com> wrote: >>> +1 for that. Stumbled over that once or twice in the past and wondered what the reasons were. Mit freundlichen Grüßen, *Christian Beikov* Am 27.03.2017 um 19:37 schrieb Steve Ebersole: > In all versions of Hibernate to-date we have required that the Java >> type of > an id be Serializable. Strictly speaking JPA has no such restriction >> - it > says ids can be any Object type *unless* the entity is to be >> serialized, in > which case the id must be Serializable (duh). > > As we transition into 6.0, I wonder if we want to loosen this >> restriction > and allow the id to be any Object type as well. There really is no >> valid > reason (beyond the obvious case explicitly discussed in the JPA spec) >> for > requiring the id to be Serializable. > > WDYT? > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev 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
