[hibernate-dev] Bug fixes around JP-QL and more: Hibernate OGM 4.1.2 released
Hi, It’s my pleasure to announce the release of Hibernate OGM 4.1.2! This maintenance release fixes several bugs, e.g. around JP-QL, using Hibernate OGM within SAAS environments and mapping byte[] properties on CouchDB. We also clarified several issues in the reference guide. Please check out the release announcement for the details [1]. --Gunnar [1] http://in.relation.to/Bloggers/BugFixesAroundJPQLAndMoreHibernateOGM412Released ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] To identify the version of Hibernate ORM at runtime
All, it looks like people get easily confused by which version of ORM is compatible with - for example - Hibernate Search. The expected versions are documented plenty, in readme, project sources, documentation and we even remind about the expectations frequently in blog posts. Wondering if it would be more effective to have some marker in ORM, to validate at least for most critical known incompatibilities at runtime? I realize there is no 100% foolproof in any possible solution, but providing a nice error message to 90% of these cases could be helpful to a large population already, and doesn't seem too complex for us to do. I guess it could be simple enough to use the existing org.hibernate.Version ? Or we could improve on those methods, if not actually adding some easy to consume resource in the orm jars. WDYT? Sanne - https://hibernate.atlassian.net/browse/HSEARCH-1816 - http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] To identify the version of Hibernate ORM at runtime
> Or we could improve on those methods, if not actually adding some easy to consume resource in the orm jars. Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF -> key "Implementation-Version"? Based on that you should be able to raise a meaningful error if the ORM version is "too old". It doesn't help with incompatible future ORM versions, but it should improve the experience in some cases. 2015-03-02 14:40 GMT+01:00 Sanne Grinovero : > All, > it looks like people get easily confused by which version of ORM is > compatible with - for example - Hibernate Search. > > The expected versions are documented plenty, in readme, project > sources, documentation and we even remind about the expectations > frequently in blog posts. > > Wondering if it would be more effective to have some marker in ORM, to > validate at least for most critical known incompatibilities at > runtime? > > I realize there is no 100% foolproof in any possible solution, but > providing a nice error message to 90% of these cases could be helpful > to a large population already, and doesn't seem too complex for us to > do. > > I guess it could be simple enough to use the existing > org.hibernate.Version ? > Or we could improve on those methods, if not actually adding some easy > to consume resource in the orm jars. > > WDYT? > > Sanne > > - https://hibernate.atlassian.net/browse/HSEARCH-1816 > - > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 > ___ > 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] To identify the version of Hibernate ORM at runtime
Hmm, I had used to set the set the Specification-* entries too, but it looks like those are no longer there :( On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling wrote: > > Or we could improve on those methods, if not actually adding some easy > to consume resource in the orm jars. > > Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF -> > key "Implementation-Version"? > > Based on that you should be able to raise a meaningful error if the ORM > version is "too old". It doesn't help with incompatible future ORM > versions, but it should improve the experience in some cases. > > 2015-03-02 14:40 GMT+01:00 Sanne Grinovero : > > > All, > > it looks like people get easily confused by which version of ORM is > > compatible with - for example - Hibernate Search. > > > > The expected versions are documented plenty, in readme, project > > sources, documentation and we even remind about the expectations > > frequently in blog posts. > > > > Wondering if it would be more effective to have some marker in ORM, to > > validate at least for most critical known incompatibilities at > > runtime? > > > > I realize there is no 100% foolproof in any possible solution, but > > providing a nice error message to 90% of these cases could be helpful > > to a large population already, and doesn't seem too complex for us to > > do. > > > > I guess it could be simple enough to use the existing > > org.hibernate.Version ? > > Or we could improve on those methods, if not actually adding some easy > > to consume resource in the orm jars. > > > > WDYT? > > > > Sanne > > > > - https://hibernate.atlassian.net/browse/HSEARCH-1816 > > - > > > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 > > ___ > > 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] To identify the version of Hibernate ORM at runtime
On 2 March 2015 at 15:05, Steve Ebersole wrote: > Hmm, I had used to set the set the Specification-* entries too, but it looks > like those are no longer there :( Just out of curiosity, what would these define? But not too bad, I think I'll simply rely on parsing org.hibernate.Version#getVersionString > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling wrote: >> >> > Or we could improve on those methods, if not actually adding some easy >> to consume resource in the orm jars. >> >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF >> -> >> key "Implementation-Version"? Right that could work as well. There will be many manifests on classpath I'd guess, but we could identify the one from ORM from the other keys, such as Bundle-Name, Implementation-Vendor-Id, etc.. But how would that be better over using org.hibernate.Version#getVersionString ? I guess one benefit of basing on resources would be that we'd be able to check for duplicate ORM jars, but are we interested into going to that length? It wouldn't be fool-proof either, as in a modular world it's possible that ORM version A has visibility on Search (and attempts to start it) but Search could be validating on resources from ORM module B - and not be able to "see" ORM version A's resources. I guess I'd stick with the method invocation, as obviously we can't implement a bullet proof validation either way. Sanne >> >> Based on that you should be able to raise a meaningful error if the ORM >> version is "too old". It doesn't help with incompatible future ORM >> versions, but it should improve the experience in some cases. >> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero : >> >> > All, >> > it looks like people get easily confused by which version of ORM is >> > compatible with - for example - Hibernate Search. >> > >> > The expected versions are documented plenty, in readme, project >> > sources, documentation and we even remind about the expectations >> > frequently in blog posts. >> > >> > Wondering if it would be more effective to have some marker in ORM, to >> > validate at least for most critical known incompatibilities at >> > runtime? >> > >> > I realize there is no 100% foolproof in any possible solution, but >> > providing a nice error message to 90% of these cases could be helpful >> > to a large population already, and doesn't seem too complex for us to >> > do. >> > >> > I guess it could be simple enough to use the existing >> > org.hibernate.Version ? >> > Or we could improve on those methods, if not actually adding some easy >> > to consume resource in the orm jars. >> > >> > WDYT? >> > >> > Sanne >> > >> > - https://hibernate.atlassian.net/browse/HSEARCH-1816 >> > - >> > >> > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 >> > ___ >> > 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] To identify the version of Hibernate ORM at runtime
It was the "release family". 4.3, or 4.2... On Mar 2, 2015 9:22 AM, "Sanne Grinovero" wrote: > On 2 March 2015 at 15:05, Steve Ebersole wrote: > > Hmm, I had used to set the set the Specification-* entries too, but it > looks > > like those are no longer there :( > > Just out of curiosity, what would these define? > But not too bad, I think I'll simply rely on parsing > org.hibernate.Version#getVersionString > > > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling > wrote: > >> > >> > Or we could improve on those methods, if not actually adding some easy > >> to consume resource in the orm jars. > >> > >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF > >> -> > >> key "Implementation-Version"? > > Right that could work as well. There will be many manifests on > classpath I'd guess, but we could identify the one from ORM from the > other keys, such as Bundle-Name, Implementation-Vendor-Id, etc.. > But how would that be better over using > org.hibernate.Version#getVersionString ? > > I guess one benefit of basing on resources would be that we'd be able > to check for duplicate ORM jars, but are we interested into going to > that length? It wouldn't be fool-proof either, as in a modular world > it's possible that ORM version A has visibility on Search (and > attempts to start it) but Search could be validating on resources from > ORM module B - and not be able to "see" ORM version A's resources. I > guess I'd stick with the method invocation, as obviously we can't > implement a bullet proof validation either way. > > Sanne > > >> > >> Based on that you should be able to raise a meaningful error if the ORM > >> version is "too old". It doesn't help with incompatible future ORM > >> versions, but it should improve the experience in some cases. > >> > >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero : > >> > >> > All, > >> > it looks like people get easily confused by which version of ORM is > >> > compatible with - for example - Hibernate Search. > >> > > >> > The expected versions are documented plenty, in readme, project > >> > sources, documentation and we even remind about the expectations > >> > frequently in blog posts. > >> > > >> > Wondering if it would be more effective to have some marker in ORM, to > >> > validate at least for most critical known incompatibilities at > >> > runtime? > >> > > >> > I realize there is no 100% foolproof in any possible solution, but > >> > providing a nice error message to 90% of these cases could be helpful > >> > to a large population already, and doesn't seem too complex for us to > >> > do. > >> > > >> > I guess it could be simple enough to use the existing > >> > org.hibernate.Version ? > >> > Or we could improve on those methods, if not actually adding some easy > >> > to consume resource in the orm jars. > >> > > >> > WDYT? > >> > > >> > Sanne > >> > > >> > - https://hibernate.atlassian.net/browse/HSEARCH-1816 > >> > - > >> > > >> > > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 > >> > ___ > >> > 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] To identify the version of Hibernate ORM at runtime
2015-03-02 16:22 GMT+01:00 Sanne Grinovero : > On 2 March 2015 at 15:05, Steve Ebersole wrote: > > Hmm, I had used to set the set the Specification-* entries too, but it > looks > > like those are no longer there :( > > Just out of curiosity, what would these define? > But not too bad, I think I'll simply rely on parsing > org.hibernate.Version#getVersionString > > > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling > wrote: > >> > >> > Or we could improve on those methods, if not actually adding some easy > >> to consume resource in the orm jars. > >> > >> Doesn't such resource already exist, in the form of META-INF/MANIFEST.MF > >> -> > >> key "Implementation-Version"? > > Right that could work as well. There will be many manifests on > classpath I'd guess, but we could identify the one from ORM from the > other keys, such as Bundle-Name, Implementation-Vendor-Id, etc.. > But how would that be better over using > org.hibernate.Version#getVersionString ? > The "Implementation-Version" value can be obtained through a standard API: Session.class.getPackage().getImplementationVersion(); So it basically renders that custom method superfluous. No huge difference apart from that. Only pointing out that there is no need for another "easy to consume resource in the orm jars". I guess one benefit of basing on resources would be that we'd be able > to check for duplicate ORM jars, but are we interested into going to > that length? It wouldn't be fool-proof either, as in a modular world > it's possible that ORM version A has visibility on Search (and > attempts to start it) but Search could be validating on resources from > ORM module B - and not be able to "see" ORM version A's resources. I > guess I'd stick with the method invocation, as obviously we can't > implement a bullet proof validation either way. > +1 for keeping it simple. > > Sanne > > >> > >> Based on that you should be able to raise a meaningful error if the ORM > >> version is "too old". It doesn't help with incompatible future ORM > >> versions, but it should improve the experience in some cases. > >> > >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero : > >> > >> > All, > >> > it looks like people get easily confused by which version of ORM is > >> > compatible with - for example - Hibernate Search. > >> > > >> > The expected versions are documented plenty, in readme, project > >> > sources, documentation and we even remind about the expectations > >> > frequently in blog posts. > >> > > >> > Wondering if it would be more effective to have some marker in ORM, to > >> > validate at least for most critical known incompatibilities at > >> > runtime? > >> > > >> > I realize there is no 100% foolproof in any possible solution, but > >> > providing a nice error message to 90% of these cases could be helpful > >> > to a large population already, and doesn't seem too complex for us to > >> > do. > >> > > >> > I guess it could be simple enough to use the existing > >> > org.hibernate.Version ? > >> > Or we could improve on those methods, if not actually adding some easy > >> > to consume resource in the orm jars. > >> > > >> > WDYT? > >> > > >> > Sanne > >> > > >> > - https://hibernate.atlassian.net/browse/HSEARCH-1816 > >> > - > >> > > >> > > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 > >> > ___ > >> > 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] To identify the version of Hibernate ORM at runtime
On 2 March 2015 at 15:49, Gunnar Morling wrote: > > > 2015-03-02 16:22 GMT+01:00 Sanne Grinovero : >> >> On 2 March 2015 at 15:05, Steve Ebersole wrote: >> > Hmm, I had used to set the set the Specification-* entries too, but it >> > looks >> > like those are no longer there :( >> >> Just out of curiosity, what would these define? >> But not too bad, I think I'll simply rely on parsing >> org.hibernate.Version#getVersionString >> >> > On Mon, Mar 2, 2015 at 7:57 AM, Gunnar Morling >> > wrote: >> >> >> >> > Or we could improve on those methods, if not actually adding some >> >> > easy >> >> to consume resource in the orm jars. >> >> >> >> Doesn't such resource already exist, in the form of >> >> META-INF/MANIFEST.MF >> >> -> >> >> key "Implementation-Version"? >> >> Right that could work as well. There will be many manifests on >> classpath I'd guess, but we could identify the one from ORM from the >> other keys, such as Bundle-Name, Implementation-Vendor-Id, etc.. >> But how would that be better over using >> org.hibernate.Version#getVersionString ? > > > The "Implementation-Version" value can be obtained through a standard API: > > Session.class.getPackage().getImplementationVersion(); > > So it basically renders that custom method superfluous. Cool trick, I had no idea :) So why do we have those methods? Just to log it? > > No huge difference apart from that. Only pointing out that there is no need > for another "easy to consume resource in the orm jars". > >> I guess one benefit of basing on resources would be that we'd be able >> to check for duplicate ORM jars, but are we interested into going to >> that length? It wouldn't be fool-proof either, as in a modular world >> it's possible that ORM version A has visibility on Search (and >> attempts to start it) but Search could be validating on resources from >> ORM module B - and not be able to "see" ORM version A's resources. I >> guess I'd stick with the method invocation, as obviously we can't >> implement a bullet proof validation either way. > > > +1 for keeping it simple. > >> >> >> Sanne >> >> >> >> >> Based on that you should be able to raise a meaningful error if the ORM >> >> version is "too old". It doesn't help with incompatible future ORM >> >> versions, but it should improve the experience in some cases. >> >> >> >> 2015-03-02 14:40 GMT+01:00 Sanne Grinovero : >> >> >> >> > All, >> >> > it looks like people get easily confused by which version of ORM is >> >> > compatible with - for example - Hibernate Search. >> >> > >> >> > The expected versions are documented plenty, in readme, project >> >> > sources, documentation and we even remind about the expectations >> >> > frequently in blog posts. >> >> > >> >> > Wondering if it would be more effective to have some marker in ORM, >> >> > to >> >> > validate at least for most critical known incompatibilities at >> >> > runtime? >> >> > >> >> > I realize there is no 100% foolproof in any possible solution, but >> >> > providing a nice error message to 90% of these cases could be helpful >> >> > to a large population already, and doesn't seem too complex for us to >> >> > do. >> >> > >> >> > I guess it could be simple enough to use the existing >> >> > org.hibernate.Version ? >> >> > Or we could improve on those methods, if not actually adding some >> >> > easy >> >> > to consume resource in the orm jars. >> >> > >> >> > WDYT? >> >> > >> >> > Sanne >> >> > >> >> > - https://hibernate.atlassian.net/browse/HSEARCH-1816 >> >> > - >> >> > >> >> > >> >> > http://stackoverflow.com/questions/28736785/org-hibernate-impl-sessionimpl-cannot-be-cast-to-org-hibernate-engine-spi-sessio/28810837#28810837 >> >> > ___ >> >> > 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
