From sanne at hibernate.org Mon Nov 3 09:41:12 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 3 Nov 2014 14:41:12 +0000 Subject: [hibernate-dev] Hibernate Search 5.0.0.Beta1 released! Message-ID: The Beta1 of Hibernate Search 5 is now available! I've described all great reasons to try it out here: http://in.relation.to/Bloggers/HibernateSearchReleases500Beta1TheFinalSprintBegins One warning though: the server hosting the blog is having some critical hardware problems and is being replaced, it can't currently handle any non-trivial load. If you see errors at the link, please try again later. Sanne From gbadner at redhat.com Mon Nov 3 14:56:42 2014 From: gbadner at redhat.com (Gail Badner) Date: Mon, 3 Nov 2014 14:56:42 -0500 (EST) Subject: [hibernate-dev] Hibernate ORM 4.3.7.Final and 4.2.15.Final Released In-Reply-To: <2145012636.4828607.1415044321346.JavaMail.zimbra@redhat.com> Message-ID: <169377276.4831985.1415044602167.JavaMail.zimbra@redhat.com> For details, see: http://in.relation.to/Bloggers/HibernateORM437FinalAnd4216FinalReleased These were actually released on October 30. The announcement has been delayed because the server hosting the blog is having critical hardware problems and I was not able to post my entry until today. If you have problems with that link, please try again later. Gail Badner Red Hat, Hibernate ORM From m.schipperheyn at gmail.com Tue Nov 4 09:47:51 2014 From: m.schipperheyn at gmail.com (Marc Schipperheyn) Date: Tue, 4 Nov 2014 12:47:51 -0200 Subject: [hibernate-dev] Was HSearch 4.4.5 ever released to Maven? Message-ID: I see it in Jira as a version, but in Maven only 4.4.4.Final is available. From sanne at hibernate.org Tue Nov 4 10:06:30 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 4 Nov 2014 15:06:30 +0000 Subject: [hibernate-dev] Was HSearch 4.4.5 ever released to Maven? In-Reply-To: References: Message-ID: Hi Marc, no sorry, I started the release: it was tagged and uploaded to our Nexus, and then had connectivity issues; after that I had some travel last week and when I could get back to it the staging repository had expired so I'll have to repeat the release from the tag. But the tag is valid, in case you need it urgently. I'll try to cleanup the mess at end of this week. Sanne On 4 November 2014 14:47, Marc Schipperheyn wrote: > I see it in Jira as a version, but in Maven only 4.4.4.Final is available. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Nov 6 10:42:41 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 6 Nov 2014 15:42:41 +0000 Subject: [hibernate-dev] Jira + pull requests In-Reply-To: <547cc56278f94858768becd2c38d0d@ip-10-0-3-132> References: <547cc56278f94858768becd2c38d0d@ip-10-0-3-132> Message-ID: Because the automated integration doesn't work at all if you rebase. I've considered disabling that JIRA plugin.. for now I'm hoping it will improve in future. On 6 November 2014 15:26, Hardy wrote: > OOI, why do you still add the pull request links manually to Jira. It's > nicely and automatically integrated anyways. > > -- hardy > > From sanne at hibernate.org Thu Nov 6 14:42:19 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 6 Nov 2014 19:42:19 +0000 Subject: [hibernate-dev] in.relation.to fixed Message-ID: All, the blog platform finally finished its migration to the new servers. If you still see errors, please let us know as that would be a new problem. Sanne From steve at hibernate.org Sat Nov 8 11:30:04 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 8 Nov 2014 10:30:04 -0600 Subject: [hibernate-dev] ORM build - IDE imports Message-ID: I have been thinking of ways to make importing ORM into IDE more transparent. My thinking is from the IntelliJ pov and the specific issues I have run into there. I wanted to run my thoughts past y'all to see if they helped with Eclipse and/or other IDEs. ----- The main thing I see is trouble with the generated-src dir. IntelliJ automatically "excludes" the build directory which is actually perfect, generally speaking. However, we put generated-src under the build dir so it gets excluded by extension as well. That's why after import we need to adjust excluded dirs and source dirs. My suggestion here is to move generated-src out from under the build dir, making it on level with src and target. So we'd have: {projectRoot} +- generated-src +- src \- target generated-src and target would both be directories that are created by the build and are git-ignored. The point being that IntelliJ would still exclude target as the main build dir, but generated-src is no longer under that dir and would not be excluded. In my experience the import marks the generated source dirs properly other than them being transitively excluded. ---- A related issue is the execution of source generators. This has already been partially been addressed. Today we have a split between: 1) source generators that generate sources required at compile time (antlr, jaxb, jpa-metamodel-gen, etc) 2) source generators that generate sources required at run time (currently only logging). There is also a concern here between AP-based generators and non-AP-based generators. And unfortunately they split across the compile/run time requirement. I am not really sure of an ideal solution here. And the situation is compounded by the fact that IntelliJ won't let us apply annotation processors to its compile process because of the hibernate-testing module circularity :( To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as the best-case scenario. But that is not likely to happen soon. And coupled with the fact of the IntelliJ limitation due to hibernate-testing circularity, I am not sure it would practically help. It seems to me the only real option currently is to expect a full compile prior to import. Better suggestions? ---- Speaking of the hibernate-testing circularity, I do still want to get rid of that. Currently I have been waiting on Gradle adding support for publishing multiple artifacts from a project (module). The idea being that we'd fold the source from hibernate-testing into hibernate-core and have hibernate-core produce and publish both artifacts. Currently Gradle only supports a single publication from a project. So the hang up really is publishing hibernate-testing to nexus. I think we all agreed last time this was discussed that publishing hibernate-testing to nexus was important enough to hold off on. Do I remember that correctly? Is that still the situation? From gunnar at hibernate.org Mon Nov 10 04:20:36 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 10 Nov 2014 10:20:36 +0100 Subject: [hibernate-dev] ORM build - IDE imports In-Reply-To: References: Message-ID: Hi, 2014-11-08 17:30 GMT+01:00 Steve Ebersole : > I have been thinking of ways to make importing ORM into IDE more > transparent. My thinking is from the IntelliJ pov and the specific issues > I have run into there. I wanted to run my thoughts past y'all to see if > they helped with Eclipse and/or other IDEs. > > ----- > > The main thing I see is trouble with the generated-src dir. IntelliJ > automatically "excludes" the build directory which is actually perfect, > generally speaking. However, we put generated-src under the build dir so > it gets excluded by extension as well. That's why after import we need to > adjust excluded dirs and source dirs. My suggestion here is to move > generated-src out from under the build dir, making it on level with src and > target. So we'd have: > > {projectRoot} > +- generated-src > +- src > \- target > > generated-src and target would both be directories that are created by the > build and are git-ignored. The point being that IntelliJ would still > exclude target as the main build dir, but generated-src is no longer under > that dir and would not be excluded. In my experience the import marks the > generated source dirs properly other than them being transitively excluded. > Having dirs with generated sources under "target" is a common situation, so I'm surprised that it isn't handled smoothly by the IntelliJ/Gradle combo. In Eclipse/Maven generated source dirs under "target" are automatically added as source folder upon import of a Maven project. For most (Maven) plug-ins generating sources this works out of the box, for others one can explicitly add the source source folder in the Maven POM so it will be recognized during IDE import. Maybe a similar approach exists for Gradle? ---- > > A related issue is the execution of source generators. This has already > been partially been addressed. Today we have a split between: > 1) source generators that generate sources required at compile time (antlr, > jaxb, jpa-metamodel-gen, etc) > 2) source generators that generate sources required at run time (currently > only logging). > > There is also a concern here between AP-based generators and non-AP-based > generators. And unfortunately they split across the compile/run time > requirement. I am not really sure of an ideal solution here. And the > situation is compounded by the fact that IntelliJ won't let us apply > annotation processors to its compile process because of the > hibernate-testing module circularity :( > > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as the > best-case scenario. But that is not likely to happen soon. And coupled > with the fact of the IntelliJ limitation due to hibernate-testing > circularity, I am not sure it would practically help. > It seems to me the only real option currently is to expect a full compile > prior to import. > > Better suggestions? > ---- > > Speaking of the hibernate-testing circularity, I do still want to get rid > of that. Currently I have been waiting on Gradle adding support for > publishing multiple artifacts from a project (module). The idea being that > we'd fold the source from hibernate-testing into hibernate-core and have > hibernate-core produce and publish both artifacts. Currently Gradle only > supports a single publication from a project. So the hang up really is > publishing hibernate-testing to nexus. I think we all agreed last time > this was discussed that publishing hibernate-testing to nexus was important > enough to hold off on. Do I remember that correctly? Is that still the > situation? > Removing the circularity would be great, it seems to be the cause of some of the issues. It'd also give a better experience for Eclipse users as this is reported as an error during import (which then can be suppressed). For Hibernate OGM we don't have a dependency to hibernate-testing, so we wouldn't need it to be in Nexus. --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From galder at redhat.com Mon Nov 10 05:17:47 2014 From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=) Date: Mon, 10 Nov 2014 11:17:47 +0100 Subject: [hibernate-dev] Session factory name & clustering Message-ID: <3A92E31E-B7A7-47B3-AB11-F4B8150AEA63@redhat.com> Hi all, Re: http://stackoverflow.com/questions/26110918/infinispan-marshalling-error-for-hibernate-entity-with-composite-primary-key Re: https://github.com/hibernate/hibernate-orm/pull/820 Seems like the issue is resolved by making sure Session Factories have the same name. Is this something new? I?ve never had the need to set it in order to get Hibernate 2LC clustered tests working. None of my unit tests set the session factory name. One of my most recent demos uses JPA, and never had to set hibernate.session_factory_name property. Or is this due to the peculiarity of the Entity the user has? I?ve run some tests locally and SessionFactoryImpl.readResolve() does not seem to get called. @Paul/@Scott, have you seen anything similar before? Cheers, -- Galder Zamarre?o galder at redhat.com twitter.com/galderz From steve at hibernate.org Mon Nov 10 07:40:08 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 10 Nov 2014 06:40:08 -0600 Subject: [hibernate-dev] Session factory name & clustering In-Reply-To: <3A92E31E-B7A7-47B3-AB11-F4B8150AEA63@redhat.com> References: <3A92E31E-B7A7-47B3-AB11-F4B8150AEA63@redhat.com> Message-ID: It would depend on what is inside the CacheKey, which is the key object Hibernate passes to the second-level cache. Usually this situation comes up with the identifier Type(s), especially in the case of composite identifiers. Some of the Type implementations hold reference to the SessionFactory. Serializing those properly depends on being able to resolve the proper SessionFactory reference on deser, which can happen based on UUID (same JVM) or name (across JVMs). On Mon, Nov 10, 2014 at 4:17 AM, Galder Zamarre?o wrote: > Hi all, > > Re: > http://stackoverflow.com/questions/26110918/infinispan-marshalling-error-for-hibernate-entity-with-composite-primary-key > Re: https://github.com/hibernate/hibernate-orm/pull/820 > > Seems like the issue is resolved by making sure Session Factories have the > same name. > > Is this something new? I?ve never had the need to set it in order to get > Hibernate 2LC clustered tests working. None of my unit tests set the > session factory name. One of my most recent demos uses JPA, and never had > to set hibernate.session_factory_name property. > > Or is this due to the peculiarity of the Entity the user has? I?ve run > some tests locally and SessionFactoryImpl.readResolve() does not seem to > get called. > > @Paul/@Scott, have you seen anything similar before? > > Cheers, > -- > Galder Zamarre?o > galder at redhat.com > twitter.com/galderz > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Nov 10 07:46:50 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 10 Nov 2014 06:46:50 -0600 Subject: [hibernate-dev] ORM build - IDE imports In-Reply-To: References:

Message-ID: > > >> Having dirs with generated sources under "target" is a common situation, > so I'm surprised that it isn't handled smoothly by the IntelliJ/Gradle > combo. > > In Eclipse/Maven generated source dirs under "target" are automatically > added as source folder upon import of a Maven project. For most (Maven) > plug-ins generating sources this works out of the box, for others one can > explicitly add the source source folder in the Maven POM so it will be > recognized during IDE import. > > Maybe a similar approach exists for Gradle? > Like I said initially, the import does already mark the generated source dirs as sources. That is not the problem. The problem is IntelliJ's notion of "excluded dirs" which allows users to tell IntelliJ to not scan those dirs; think of it as an "ignore" flag. The trouble is that the import marks the Gradle build dir (our target dir) as excluded. So even though the directories under target are marked as source, it is irrelevant because the parent dir has been marked excluded. From steve at hibernate.org Mon Nov 10 08:04:18 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 10 Nov 2014 07:04:18 -0600 Subject: [hibernate-dev] ORM build - IDE imports In-Reply-To: <20141110094711.GA34385@sarmakand.lan> References: <20141110094711.GA34385@sarmakand.lan> Message-ID: > > > Personally, I am not a big fan of changing build structure for the purpose > of an > IDE. generated-src belong imo into target. > > That said, I know the troubles of having to manually adjust the Idea > configuration > after importing. If it bothers you so much or if you had several reports > of people > having problems setting up the project in the IDE, I's say go for it. > Yes, this is completely a pragmatic consideration. I set the build up with generated-src under target because that is what I believe is proper in the idyllic sense. But at some point I'd like to have an import that JustWorks(tm). > > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as > the > > best-case scenario. > > Not sure what you mean? Are you referring to the actual annotation > processor module > or do you mean that you want to statically check in the generated meta > model classes > needed for our tests in the hibernate-core/hibernate-entitymanager module? > I assume > the latter. Again, not a big fan. > No, I actually mean the former. Probably as an alternative to the AP-based generation, I think a non-AP solution would be good. After having talked to David a few times about this, I believe annotation processing is not the proper way to be generating these classes. My new belief is that annotation processors that generate code that is then needed to compile is bad mojo. > > > It seems to me the only real option currently is to expect a full compile > > prior to import. > > Right. Something I would recommend anyways. > Dunno here. Often my initial touch point with a project is to check out the code and import it into the IDE. And I think that I am not unusual in that sense, so I think there is a ton of value in that working smoothly. > Speaking of the hibernate-testing circularity, I do still want to get rid > > of that. Currently I have been waiting on Gradle adding support for > > publishing multiple artifacts from a project (module). > > That would be nice. Is there an issue for that? Did they agree on > implementing > it? > They said it was something they wanted to do. I'll follow up to see if it was ever done. From hardy at hibernate.org Mon Nov 10 08:26:24 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Mon, 10 Nov 2014 14:26:24 +0100 Subject: [hibernate-dev] ORM build - IDE imports In-Reply-To: References: <20141110094711.GA34385@sarmakand.lan> Message-ID: <20141110132624.GC36179@sarmakand.lan> Hi, > > > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based as > > the > > > best-case scenario. > > > > Not sure what you mean? Are you referring to the actual annotation > > processor module > > or do you mean that you want to statically check in the generated meta > > model classes > > needed for our tests in the hibernate-core/hibernate-entitymanager module? > > I assume > > the latter. Again, not a big fan. > > > > No, I actually mean the former. Probably as an alternative to the AP-based > generation, I think a non-AP solution would be good Interesting. For me the metamodel generation is a classic example for using an annotation processor. > After having talked > to David a few times about this, I believe annotation processing is not the > proper way to be generating these classes What would be the right way then in your opinion? > annotation processors that generate code that is then needed to compile Not sure. IMO the annotation processor is designed for exactly that. In fact if you run the processor as part of the main compilation it does generation and compilation in the same build phase. I don't see the bad mojo here. > > > It seems to me the only real option currently is to expect a full compile > > > prior to import. > > > > Right. Something I would recommend anyways. > > Dunno here. Often my initial touch point with a project is to check out > the code and import it into the IDE. And I think that I am not unusual in > that sense, so I think there is a ton of value in that working smoothly. Sure, there is value in making it work smoothly. However, I prefer to start the command line build first after checking out the code. > > That would be nice. Is there an issue for that? Did they agree on > > implementing > > it? > > > > They said it was something they wanted to do. I'll follow up to see if it > was ever done. Cool --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20141110/9b809a9b/attachment.bin From steve at hibernate.org Mon Nov 10 09:48:41 2014 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 10 Nov 2014 08:48:41 -0600 Subject: [hibernate-dev] ORM build - IDE imports In-Reply-To: <20141110132624.GC36179@sarmakand.lan> References: <20141110094711.GA34385@sarmakand.lan> <20141110132624.GC36179@sarmakand.lan> Message-ID: On Mon, Nov 10, 2014 at 7:26 AM, Hardy Ferentschik wrote: > Hi, > > > > > To be honest I think I'd alter jpa-metamodel-gen to not be AP-based > as > > > the > > > > best-case scenario. > > > > > > Not sure what you mean? Are you referring to the actual annotation > > > processor module > > > or do you mean that you want to statically check in the generated meta > > > model classes > > > needed for our tests in the hibernate-core/hibernate-entitymanager > module? > > > I assume > > > the latter. Again, not a big fan. > > > > > > > No, I actually mean the former. Probably as an alternative to the > AP-based > > generation, I think a non-AP solution would be good > > Interesting. For me the metamodel generation is a classic example for using > an annotation processor. > I think that's true *if* the compilation unit producing the metamodel is not also the one consuming it. For example a CRM project that produces and bundles a JPA static metamodel of its domain model for developer use. However, in cases where we try to both produce and consume the static metamodel from the same compilation unit as we do in our usages. I think about the whole point of AP, and as a user especially this static metamodel. So I am writing code in which I am relying on this static metamodel for type-safety, but I cannot even do that as the static metamodel types dont even exist. Until I introduce some unnatural (imo) step into the development process: develop, then compile so that I can develop some more. > > After having talked > > to David a few times about this, I believe annotation processing is not > the > > proper way to be generating these classes > > What would be the right way then in your opinion? > Well again I am pointing out the appropriateness of each. I think the AP approach makes sense in certain cases. Just that our case within the Hibernate build is not one of these. I think a tool leveraging source code reading/analysis > > > annotation processors that generate code that is then needed to compile > > Not sure. IMO the annotation processor is designed for exactly that. In > fact if you > run the processor as part of the main compilation it does generation and > compilation > in the same build phase. I don't see the bad mojo here. > I consider it bad mojo because I load it up into the IDE and see red all over the place. Yes I realize we have the same with Antlr and/or JAXB. But I can completely rationalize running a source code generation *tool* here. I have a hard time making that rationalization for running the compiler in order to see if my code will compile due to sources that are not there :) > > > > It seems to me the only real option currently is to expect a full > compile > > > > prior to import. > > > > > > Right. Something I would recommend anyways. > I fully understand about needing/recommending some task prior to importing. Specifically a source-generation task. I just don't think I am alone in not immediately assuming/grokking a full compilation as the source-generation task. > > > > Dunno here. Often my initial touch point with a project is to check out > > the code and import it into the IDE. And I think that I am not unusual > in > > that sense, so I think there is a ton of value in that working smoothly. > > Sure, there is value in making it work smoothly. However, I prefer to > start the > command line build first after checking out the code. > I am not so sure that is the norm. For sure it is not generally what I do at least. Projects tend to have such widely differing build assumptions and requirements. When you first check it out, how do you know what command line to do? From smarlow at redhat.com Mon Nov 10 11:07:18 2014 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 10 Nov 2014 11:07:18 -0500 Subject: [hibernate-dev] Session factory name & clustering In-Reply-To: References: <3A92E31E-B7A7-47B3-AB11-F4B8150AEA63@redhat.com> Message-ID: <5460E2B6.50509@redhat.com> On 11/10/2014 07:40 AM, Steve Ebersole wrote: > It would depend on what is inside the CacheKey, which is the key object > Hibernate passes to the second-level cache. Usually this situation > comes up with the identifier Type(s), especially in the case of > composite identifiers. Some of the Type implementations hold reference > to the SessionFactory. Serializing those properly depends on being able > to resolve the proper SessionFactory reference on deser, which can > happen based on UUID (same JVM) or name (across JVMs). > > On Mon, Nov 10, 2014 at 4:17 AM, Galder Zamarre?o > wrote: > > Hi all, > > Re: > http://stackoverflow.com/questions/26110918/infinispan-marshalling-error-for-hibernate-entity-with-composite-primary-key This user found the "hibernate.session_factory_name" + "hibernate.session_factory_name_is_jndi" settings and HHH-6822. > Re: https://github.com/hibernate/hibernate-orm/pull/820 > > Seems like the issue is resolved by making sure Session Factories > have the same name. > > Is this something new? I?ve never had the need to set it in order to > get Hibernate 2LC clustered tests working. None of my unit tests set > the session factory name. One of my most recent demos uses JPA, and > never had to set hibernate.session_factory_name property. > > Or is this due to the peculiarity of the Entity the user has? I?ve > run some tests locally and SessionFactoryImpl.readResolve() does not > seem to get called. If the local test serializes the SF UUID and then deserializes from the same JVM, the test should pass (as long as the same Hibernate classloader is used). If you are involving multiple JVMs, the SF UUIDs are local to each JVM, so you should see failures when deserializing on a different JVM (as the SF UUID lookup will fail). > > @Paul/@Scott, have you seen anything similar before? For EE container deployments, we set the "hibernate.session_factory_name" if the application doesn't. We set it to an application scoped unique name (deployment archive name (including sub-deployment reference) and the persistence unit name). > > Cheers, > -- > Galder Zamarre?o > galder at redhat.com > twitter.com/galderz > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From Sujit.Dhaygude at sungard.com Tue Nov 11 07:39:51 2014 From: Sujit.Dhaygude at sungard.com (Sujit.Dhaygude at sungard.com) Date: Tue, 11 Nov 2014 12:39:51 +0000 Subject: [hibernate-dev] Exception handling in hibernate Message-ID: Hi , we have a requirement to point a record for which the actual batch flush/commit has failed. Is there a generic way by which hibernate can be hooked up for exception scenario to pull back the actual entity for which DB/Hibernate Error has occurred . Most of the times we could see the hibernate is printing the error in logs which has entity ID but which is not consistent. Currently we are planning to use the Pre and Post (insert/Update/Delete) event handlers to retain the entities in Thread local and display those in case of error, but these listeners will intercept all the DB operation irrespective of success/failure . I am looking for a solution which will not impact the overall application performance and only in case of exception we need the details of entity. Regards, Sujit From Nitin.Prabhu at mastek.com Tue Nov 11 08:00:36 2014 From: Nitin.Prabhu at mastek.com (Nitin G. Prabhu) Date: Tue, 11 Nov 2014 18:30:36 +0530 Subject: [hibernate-dev] Hibernate invkoing onFlushDirty for umodified objects in Set Message-ID: <305192DBBFDF8F41AF7879DE170FDEB006AB1AFE4F@IND-MHP1MCL001.mastek.com> Hi All, I have a object with below relationship public class A { @Id @SequenceGenerator(name = "ID_GENERATOR", sequenceName = "Id_SEQ", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "ID_GENERATOR") @Column(name = "id") private BigDecimal id; @OneToMany(mappedBy = MST, orphanRemoval = true, cascade = { CascadeType.ALL}) @OrderBy("id DESC") private List b = new ArrayList(); @Column(name = "name") private String name; } When I modify class A'S SAY name attribute and say dao.persist(A) then onFlushDirty()[overridden in my Hibernate interceptor] is also invoked even if B object is not modified I am not understanding why hibernate is treating List objects to be dirty when I am trying to save the parent object A Regards, Nitin MASTEK LTD. In the US, we're called MAJESCOMASTEK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From steve at hibernate.org Thu Nov 13 13:42:45 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 13 Nov 2014 12:42:45 -0600 Subject: [hibernate-dev] Query handling : Antlr 3 versus Antlr 4 Message-ID: As most of you know already, we are planning to redesign the current Antlr-based HQL/JPQL parser in ORM for a variety of reasons. The current approach in the translator (Antlr 2 based, although Antlr 3 supports the same model) is that we actually define multiple grammars/parsers which progressively re-write the tree adding more and more semantic information; think of this as multiple passes or phases. The current code has 3 phases: 1) parsing - we simply parse the HQL/JPQL query into an AST, although we do do one interesting (and uber-important!) re-write here where we "hoist" the from clause in front of all other clauses. 2) rough semantic analysis - the current code, to be honest, sucks here. The end result of this phase is a tree that mixes normalized semantic information with lots of SQL fragments. It is extremely fugly 3) rendering to SQL The idea of phases is still the best way to attack this translation imo. I just think we did not implement the phases very well before; we were just learning Antlr at the time. So part of the redesign here is to leverage our better understanding of Antlr and design some better trees. The other big reason is to centralize the generation of SQL into one place rather than the 3 different places we do it today (not to mention the many, many places we render SQL fragments). Part of the process here is to decide which parser to use. Antlr 2 is ancient :) I used Antlr 3 in the initial prototyping of this redesign because it was the most recent release at that time. In the interim Antlr 4 has been released. I have been evaluating whether Antlr 4 is appropriate for our needs there. Antlr 4 is a pretty big conceptual deviation from Antlr 2/3 in quite a few ways. Generally speaking, Antlr 4 is geared more towards interpreting rather than translating/transforming. It can handle "transformation" if the transformation is the final step in the process. Transformations is where tree re-writing comes in handy. First lets step back and look at the "conceptual model" of Antlr 4. The grammar is used to produce: 1) the parser - takes the input and builds a "parse tree" based on the rules of the lexer and grammar. 2) listener/visitor for parse-tree traversal - can optionally generate listeners or visitors (or both) for traversing the parse tree (output from parser). There are 2 highly-related changes that negatively impact us: 1) no tree grammars/parsers 2) no tree re-writing Our existing translator is fundamentally built on the concepts of tree parsers and tree re-writing. Even the initial prototypes for the redesign (and the current state of hql-parser which Sanne and Gunnar picked up from there) are built on those concepts. So moving to Antlr 4 in that regard does represent a risk. How big of a risk, and whether that risk is worth it, is what we need to determine. What does all this mean in simple, practical terms? Let's look at a simple query: "select c.headquarters.state.code from Company c". Simple syntactic analysis will produce a tree something like: [QUERY] [SELECT] [DOT] [DOT] [DOT] [IDENT, "c"] [IDENT, "headquarters"] [IDENT, "state"] [IDENT, "code"] [FROM] [SPACE] [SPACE_ROOT] [IDENT, "Customer"] [IDENT, "c"] There is not a lot of semantic (meaning) information here. A more semantic representation of the query would look something like: [QUERY] [SELECT] [ATTRIBUTE_REF] [ALIAS_REF, ""] [IDENT, "code"] [FROM] [SPACE] [PERSISTER_REF] [ENTITY_NAME, "com.acme.Customer"] [ALIAS, "c"] [JOIN] [INNER] [ATTRIBUTE_JOIN] [IDENT, "headquarters"] [ALIAS, ""] [JOIN] [INNER] [ATTRIBUTE_JOIN] [IDENT, "state"] [ALIAS, ""] Notice especially the difference in the tree rules. This is tree re-writing, and is the major difference affecting us. Consider a specific thing like the "c.headquarters.state.code" DOT-IDENT sequence. Essentially Antlr 4 would make us deal with that as a DOT-IDENT sequence through all the phases - even SQL generation. Quite fugly. The intent of Antlr 4 in cases like this is to build up an external state table (external to the tree itself) or what Antlr folks typically refer to as "iterative tree decoration"[1]. So with Antlr 4, in generating the SQL, we would still be handling calls in terms of "c.headquarters.state.code" in the SELECT clause and resolving that through the external symbol tables. Again, with Antlr 4 we would always be walking that initial (non-semantic) tree. Unless I am missing something. I would be happy to be corrected, if anyone knows Antlr 4 better. I have also asked as part of the antlr-discussion group[2]. In my opinion though, if it comes down to us needing to walk the tree in that first form across all phases I just do not see the benefit to moving to Antlr 4. P.S. When I say SQL above I really just mean the target query language for the back-end data store whether that be SQL targeting a RDBMS for ORM or a NoSQL store for OGM. [1] I still have not fully grokked this paradigm, so I may be missing something, but... AFAICT even in this paradigm the listener/visitor rules are defined in terms of the initial parse tree rules rather than more [2] https://groups.google.com/forum/#!topic/antlr-discussion/hzF_YrzfDKo From steve at hibernate.org Thu Nov 13 13:44:14 2014 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 13 Nov 2014 12:44:14 -0600 Subject: [hibernate-dev] Exception handling in hibernate In-Reply-To: References: Message-ID: Andreas is working on some redesign of batching which should allow us to report such detailed information iirc. Andreas, what are your thoughts on doing this in the new batching code? On Tue, Nov 11, 2014 at 6:39 AM, wrote: > Hi , > we have a requirement to point a record for which the actual batch > flush/commit has failed. > Is there a generic way by which hibernate can be hooked up for exception > scenario to pull back the actual entity for which > DB/Hibernate Error has occurred . > > Most of the times we could see the hibernate is printing the error in logs > which has entity ID but which is not consistent. > > Currently we are planning to use the Pre and Post (insert/Update/Delete) > event handlers to retain the entities in Thread local > and display those in case of error, but these listeners will intercept all > the DB operation irrespective of success/failure . > > I am looking for a solution which will not impact the overall application > performance and only in case of exception we need the details of entity. > > > Regards, > Sujit > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From dreborier at gmail.com Fri Nov 14 03:35:39 2014 From: dreborier at gmail.com (andrea boriero) Date: Fri, 14 Nov 2014 09:35:39 +0100 Subject: [hibernate-dev] Exception handling in hibernate In-Reply-To: References: Message-ID: I think it can be done as part of the new redesign. On 13 November 2014 19:44, Steve Ebersole wrote: > Andreas is working on some redesign of batching which should allow us to > report such detailed information iirc. Andreas, what are your thoughts on > doing this in the new batching code? > > On Tue, Nov 11, 2014 at 6:39 AM, wrote: > > > Hi , > > we have a requirement to point a record for which the actual batch > > flush/commit has failed. > > Is there a generic way by which hibernate can be hooked up for exception > > scenario to pull back the actual entity for which > > DB/Hibernate Error has occurred . > > > > Most of the times we could see the hibernate is printing the error in > logs > > which has entity ID but which is not consistent. > > > > Currently we are planning to use the Pre and Post (insert/Update/Delete) > > event handlers to retain the entities in Thread local > > and display those in case of error, but these listeners will intercept > all > > the DB operation irrespective of success/failure . > > > > I am looking for a solution which will not impact the overall application > > performance and only in case of exception we need the details of entity. > > > > > > Regards, > > Sujit > > > > _______________________________________________ > > 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 emmanuel at hibernate.org Fri Nov 14 11:39:44 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Fri, 14 Nov 2014 17:39:44 +0100 Subject: [hibernate-dev] [OGM-452] Abstraction work between OGM internal keys and Infinispan cache keys Message-ID: <59CAB33D-C6C3-4771-881B-0C32D24D12F1@hibernate.org> Hi Gunnar, I have not implemented the new strategy yet but here is the first pass on the abstraction and contract to allow the ogm key / cache key split. Take a look if you have time. https://github.com/emmanuelbernard/hibernate-ogm/tree/OGM-452 I need to implement the new cache key types, their marshallers and eagerly initialize all caches. From sanne at hibernate.org Sat Nov 15 14:58:38 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 15 Nov 2014 19:58:38 +0000 Subject: [hibernate-dev] Hibernate ORM master - 5.0 In-Reply-To: References: Message-ID: Hi Steve, the dom4j problem applies to Java 9: it depends on internal JDK APIs which are being removed. Considering Java 9 is coming fast, I agree we should get rid of that urgently as dom4j will simply not work anymore. I was looking into the state of the (very few) small fixes which I had only fixed in master. For example HHH-7699 was previously resolved with a "Fix version:" JIRA attribute having value "5.0". This was now marked as "6.0", but also marked Resolved. In fact, it's not going to be fixed in 6.0 if nobody ports it. I could fix the specific case, but I suspect there might be many more in a similar misleading state? Maybe we should mass-reopen them, but also label them with something like "Fix can be found in branch metamodel-old" ? [1] https://hibernate.atlassian.net/browse/HHH-7699 Sanne On 31 October 2014 11:25, Steve Ebersole wrote: > One other thing I just realized wrt 5.0. Currently moving to Jandex is > marked as an optional task. However, part of the code Jandex is replacing > is that old hibernate-commons-annotations stuff. > hibernate-commons-annotations suffers from a number of problems that we > maybe should consider increasing the priority of this task as well. Most > problematic is the fact that it uses TCCL-based classloading. > > On Thu, Oct 30, 2014 at 10:44 AM, Steve Ebersole > wrote: > >> It was decided that the massive work for 5.0 including metamodel and all >> the other changes was just taking too long, and that we'd split that work >> up into a number of intermediate versions. I wanted to highlight the >> proposed breakdown and solidify the roadmaps. The preliminary breakdown is >> as follows: >> >> >> - 5.0 >> - Java 6 or 7 (?) >> - EE 7 (JPA 2.1) >> - Wildfly 9 >> - Timeline : Spring 2015 >> - Required development >> - Transition to new bootstrapping APIs >> - MetadataSources, contributors, builders, etc for building >> SessionFactory >> - Keep Configuration as a migration aid, but align its >> processing and assumptions to follow new APIs >> - New naming strategy approach (implicit and physical split) >> - Pick "important" features from metamodel work based on new >> bootstrapping API >> - automatic quoting of identifiers that are keywords >> - ??? >> - Performance improvements >> - Cachng SPI changes based on feedback from Ehcahce and >> Infinispan >> - EntityKey proposal >> - Explore unifying entry keys for actual cache provider, >> cache SPI (CacheKey) and persistence-context (EntityKey) >> - Infinispan improvements, especially in local mode. Will >> require integrating a new Infinispan version and possible changes to >> hibernate-infinispan >> - ??? >> - OGM integration >> - "after persisters built" hook >> - others? >> - Java 8 type support >> - Date/Time >> - Optional >> - Java 9 type support >> - Money/Currency >> - Optional development (as time, resources allow) >> - Discriminator based multitenancy >> - JAXB instead of dom4j. >> - extended orm.xml xsd, deprecating hbm.xml format >> - Jandex usage >> - JdbcSession >> - Hibernate Spatial integration (depends on level of dependence >> on metamodel) >> - 5.1 >> - Java 6 or 7 (?) >> - EE 7 (JPA 2.1) >> - Widfly 9, or 10 >> - Timeline : TBD (Fall 2016?) >> - Required development >> - slips from 5.0 >> - new HQL parser >> - Antlr 3 or 4? >> - unified SQL generation? or limit to HQL parsing? >> - Optional development (as time, resources allow) >> - extend JPA criteria API with support for constructs from >> Hibernate's legacy criteria API >> - extend JPA criteria API with fluent support >> - Possibly - Override EAGER fetching with LAZY (fetch profiles, >> HQL, etc) >> - 5.2 >> - (if needed) >> - Java 6 or 7 (?) >> - EE 7 (JPA 2.1) >> - Widfly 9, or 10 >> - Required development >> - splits from 5.1 >> - 6.0 >> - SE and EE support levels TBD, but at least SE 8 >> - Required development >> - metamodel >> >> >> One additional consideration... I have been told (have not verified the >> details yet myself) that Hibernate ORM will currently not run in Java 8 at >> least in part because dom4j will not work in Java 8 (maybe just the version >> we use? again, have not verified details yet). If running 5.x versions of >> Hibernate in Java 8 is important to anyone, we might need to increase the >> priority of moving to JAXB over dom4j. >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Sat Nov 15 16:12:55 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 15 Nov 2014 21:12:55 +0000 Subject: [hibernate-dev] Allowing auto-close usage for Session Message-ID: I was expecting this to be a trivial and non-API breaking change, but it turns out the close() method for Session doesn't return void, and so is not compatible with the Closeable inteface: /** * End the session by releasing the JDBC connection and cleaning up. It is * not strictly necessary to close the session but you must at least * {@link #disconnect()} it. * * @return the connection provided by the application or null. * @throws HibernateException Indicates problems cleaning up. */ public Connection close() throws HibernateException; So this change can't be applied in 4.3 yet, but I'd hope to finally send a PR for 5.0 at least; Assuming that some applications really need that Connection instance, my proposal would be to split the functionality across two methods: public Connection closeAndReturnConnection(); public void close(); Any better names / ideas? Second question: we had previously decided to implement java.io.Closeable, so that it would work also for users of Java6. But if for the above reason, this is getting into master only, then I guess we could reopen that subject: would you prefer to have it extend just java.lang.AutoCloseable ? Sanne From steve at hibernate.org Sun Nov 16 11:57:58 2014 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 16 Nov 2014 10:57:58 -0600 Subject: [hibernate-dev] Allowing auto-close usage for Session In-Reply-To: References: Message-ID: Ugh. The returning of Connection is a legacy thing that honestly makes no sense imo. I am sorry; I had forgotten it returned that. I say it makes no sense, because these are cases where the user has explicitly provided Hibernate the Connection to use when opening the Session. Its just silly imo to then think it does not know that Connection later. As you say, we are obviously stuck for 4.x. But for 5.x my vote would actually be to just change the return type, from: public Connection close() throws HibernateException; to: public void close() throws HibernateException; Then Closeable/AutoCloseable fits. As for base lining on Java 7, I am just not seeing the benefit there. On Sat, Nov 15, 2014 at 3:12 PM, Sanne Grinovero wrote: > I was expecting this to be a trivial and non-API breaking change, but > it turns out the close() method for Session doesn't return void, and > so is not compatible with the Closeable inteface: > > /** > * End the session by releasing the JDBC connection and cleaning up. > It is > * not strictly necessary to close the session but you must at least > * {@link #disconnect()} it. > * > * @return the connection provided by the application or null. > * @throws HibernateException Indicates problems cleaning up. > */ > public Connection close() throws HibernateException; > > So this change can't be applied in 4.3 yet, but I'd hope to finally > send a PR for 5.0 at least; > > Assuming that some applications really need that Connection instance, > my proposal would be to split the functionality across two methods: > > public Connection closeAndReturnConnection(); > > public void close(); > > Any better names / ideas? > > Second question: we had previously decided to implement > java.io.Closeable, so that it would work also for users of Java6. But > if for the above reason, this is getting into master only, then I > guess we could reopen that subject: would you prefer to have it extend > just java.lang.AutoCloseable ? > > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Nov 17 14:11:20 2014 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 17 Nov 2014 19:11:20 +0000 Subject: [hibernate-dev] ORM build - IDE imports In-Reply-To: References: <20141110094711.GA34385@sarmakand.lan> <20141110132624.GC36179@sarmakand.lan> Message-ID: I just tried to import it in Eclipse. Compiling it once from the command line upfront helped to reduce the errors.. but I still have 10, and while I suspect one of them relates to a bug in Eclipse's not-so-smart handling of generics, the others to me look like it shouldn't compile so I'm going to need some hand-holding on each of them. Some examples: EnhancerTask class not found: seems to be a groovy class. Do I need to setup the project as Groovy, or get some Groovy SDK installed as well? package-info.java sources in the jpamodelgen module seem to be in the wrong package - or they are missing the package declaration. They also have the wrong license header (JBoss instead of Hibernate, Apache instead of LGPL). Code snippet "CoreMatchers.