[hibernate-dev] envers + classic QueryTranslator failing test
I'm working on https://hibernate.atlassian.net/browse/HHH-9996 and I stumbled across the following test: org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest I run the test not only with Derby but also with PostgreSQL and the test fails for both. The query: select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__ where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__. originalId.REV.id <= :revision and e__.originalId.id = e2__.originalId.id) and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1 causes the error java.sql.SQLException: An attempt was made to put a data value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby while in PostgreSQL the error is org.postgresql.util.PSQLException: ERROR: operator does not exist: smallint <> bytea Hint: No operator matches the given name and argument type(s). The problem is related with org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String name) returning null for the _p0 parameter (while the correct return type should be ReivsionTyptType) this cause the wrong sql bind.. Any help is more than welcome? Thanks Andrea ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] envers + classic QueryTranslator failing test
This test was originally added for https://hibernate.atlassian.net/browse/HHH-8497 I guess my first thought is to question is why this test exists at all. It's really a question of whether we consider the classic HQL translator "supported". Stuff like this "parameter expected type" was developed specifically as part of the Antlr translator. The classic translator simply does not know this information. For what its worth, my $.02 to that question is that we should not support the classic translator. However... But then I dug a little deeper. Unless I missed it, you did not say exactly which test (method) fails. But I do not see a place where the user is executing any HQL. So that tells me this is potentially a problem specifically in how envers builds a query internally somewhere. And that, if true, is something we should address. So which test method specifically fails? On Thu, Sep 17, 2015 at 6:09 AM andrea boriero wrote: > I'm working on https://hibernate.atlassian.net/browse/HHH-9996 > and I stumbled across the following test: > > > org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest > > I run the test not only with Derby but also with PostgreSQL and the test > fails for both. > > The query: > select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__ > where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from > org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__. > originalId.REV.id <= :revision and e__.originalId.id = e2__.originalId.id) > and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1 > > causes the error java.sql.SQLException: An attempt was made to put a data > value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby > > while in PostgreSQL the error is org.postgresql.util.PSQLException: ERROR: > operator does not exist: smallint <> bytea Hint: No operator matches the > given name and argument type(s). > > The problem is related with > > org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String > name) returning null for the _p0 parameter (while the correct return type > should be ReivsionTyptType) this cause the wrong sql bind.. > > Any help is more than welcome? > > Thanks > > Andrea > ___ > 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] envers + classic QueryTranslator failing test
the failing test is testHistoryOfId1, and the query is executed inside the assert method by getAuditReader().find( IntTestEntity.class, id1, 1 ) notice that if you run directly the org.hibernate.envers.test.integration.basic.Simple class that org.hibernate.envers.test.integration.basic. ClassicQueryTranslatorFactoryTest extends, the test siucceed. So i think the problem is just related to the use of the classic translator. On 17 September 2015 at 18:07, Steve Ebersole wrote: > This test was originally added for > https://hibernate.atlassian.net/browse/HHH-8497 > > I guess my first thought is to question is why this test exists at all. > It's really a question of whether we consider the classic HQL translator > "supported". Stuff like this "parameter expected type" was developed > specifically as part of the Antlr translator. The classic translator > simply does not know this information. > > For what its worth, my $.02 to that question is that we should not support > the classic translator. However... > > But then I dug a little deeper. Unless I missed it, you did not say > exactly which test (method) fails. But I do not see a place where the user > is executing any HQL. So that tells me this is potentially a problem > specifically in how envers builds a query internally somewhere. And that, > if true, is something we should address. > > So which test method specifically fails? > > > On Thu, Sep 17, 2015 at 6:09 AM andrea boriero > wrote: > >> I'm working on https://hibernate.atlassian.net/browse/HHH-9996 >> and I stumbled across the following test: >> >> >> org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest >> >> I run the test not only with Derby but also with PostgreSQL and the test >> fails for both. >> >> The query: >> select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__ >> where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from >> org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__. >> originalId.REV.id <= :revision and e__.originalId.id = >> e2__.originalId.id) >> and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1 >> >> causes the error java.sql.SQLException: An attempt was made to put a data >> value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby >> >> while in PostgreSQL the error is org.postgresql.util.PSQLException: ERROR: >> operator does not exist: smallint <> bytea Hint: No operator matches the >> given name and argument type(s). >> >> The problem is related with >> >> org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String >> name) returning null for the _p0 parameter (while the correct return type >> should be ReivsionTyptType) this cause the wrong sql bind.. >> >> Any help is more than welcome? >> >> Thanks >> >> Andrea >> ___ >> 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] envers + classic QueryTranslator failing test
Yes, but the more important point to me is whether the problem here really is the classic translator or envers. Just look at the API call you posted: getAuditReader().find( IntTestEntity.class, id1, 1 ) Why should that be dependent on the HQL translator used? Since envers creates the HQL it seems reasonable that it can probably build valid HQL. That or it could bind the parameter better. On Thu, Sep 17, 2015 at 12:36 PM andrea boriero wrote: > the failing test is testHistoryOfId1, > and the query is executed inside the assert method by getAuditReader().find( > IntTestEntity.class, id1, 1 ) > > notice that if you run directly the > org.hibernate.envers.test.integration.basic.Simple > class that org.hibernate.envers.test.integration.basic. > ClassicQueryTranslatorFactoryTest extends, the test siucceed. So i think > the problem is just related to the use of the classic translator. > > On 17 September 2015 at 18:07, Steve Ebersole wrote: > >> This test was originally added for >> https://hibernate.atlassian.net/browse/HHH-8497 >> >> I guess my first thought is to question is why this test exists at all. >> It's really a question of whether we consider the classic HQL translator >> "supported". Stuff like this "parameter expected type" was developed >> specifically as part of the Antlr translator. The classic translator >> simply does not know this information. >> >> For what its worth, my $.02 to that question is that we should not >> support the classic translator. However... >> >> But then I dug a little deeper. Unless I missed it, you did not say >> exactly which test (method) fails. But I do not see a place where the user >> is executing any HQL. So that tells me this is potentially a problem >> specifically in how envers builds a query internally somewhere. And that, >> if true, is something we should address. >> >> So which test method specifically fails? >> >> >> On Thu, Sep 17, 2015 at 6:09 AM andrea boriero >> wrote: >> >>> I'm working on https://hibernate.atlassian.net/browse/HHH-9996 >>> and I stumbled across the following test: >>> >>> >>> org.hibernate.envers.test.integration.basic.ClassicQueryTranslatorFactoryTest >>> >>> I run the test not only with Derby but also with PostgreSQL and the test >>> fails for both. >>> >>> The query: >>> select e__ from org.hibernate.envers.test.entities.IntTestEntity_AUD e__ >>> where e__.originalId.REV.id = (select max(e2__.originalId.REV.id) from >>> org.hibernate.envers.test.entities.IntTestEntity_AUD e2__ where e2__. >>> originalId.REV.id <= :revision and e__.originalId.id = >>> e2__.originalId.id) >>> and e__.REVTYPE <> :_p0 and e__.originalId.id = :_p1 >>> >>> causes the error java.sql.SQLException: An attempt was made to put a data >>> value of type 'byte[]' into a data value of type 'SMALLINT'. in Derby >>> >>> while in PostgreSQL the error is org.postgresql.util.PSQLException: >>> ERROR: >>> operator does not exist: smallint <> bytea Hint: No operator matches >>> the >>> given name and argument type(s). >>> >>> The problem is related with >>> >>> org.hibernate.hql.internal.classic.QueryTranslatorImpl$ParameterTranslations#getNamedParameterExpectedType(String >>> name) returning null for the _p0 parameter (while the correct return >>> type >>> should be ReivsionTyptType) this cause the wrong sql bind.. >>> >>> Any help is more than welcome? >>> >>> Thanks >>> >>> Andrea >>> ___ >>> 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] A few questions about Search 5.5.0
Hi, I upgraded our framework to 5.5.0 and I have a few questions about it. == First, I had to remove the existing indexes otherwise I had exceptions about version of the index. Is this expected? As far as I remember, it's been a long time since we had to remove the indexes after an upgrade. Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))): -11 (needs to be between 1071082519 and 1071082519). This version of Lucene only supports indexes created with release 4.0 and later. Maybe it should be integrated in the blog post that one might need to clean up indexes if they come from before the switch to Lucene 4? == Second, I have warnings like that in my logs: HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not configured for entity type fr.openwide.helios.core.business.contract.model.HeliosContract mapped to index fr.openwide.helios.core.business.contract.model.HeliosContract, thus an uninverting reader must be created. You should declare the missing sort fields using @SortField. Shouldn't it be @Sort*able*Field? == And finally, since recently, it's necessary to sort dates using SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this information in the blog posts of any releases. Or did I miss something? -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
