[Hibernate-JIRA] Created: (HHH-2321) ClassCastException caused when Hibernate caches instance under user provided key
by Dmitri Colebatch (JIRA)
ClassCastException caused when Hibernate caches instance under user provided key
--------------------------------------------------------------------------------
Key: HHH-2321
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2321
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0 cr1
Environment: Hibernate 3.2.0.CR1, MySQL 4.0.18
Reporter: Dmitri Colebatch
Priority: Trivial
I haven't looked into this in detail, but am pretty confident that my reading of this is correct. I'm trying to interface into bugzilla's database and have used the tools to generate some classes for use. I'm just mocking something up and so have the following code snippet:
Product product = (Product) session.load(Product.class, 1);
// ....
Bug bug = new Bug();
// ...
bug.setProduct(product);
// ...
// tx.commit();
On the commit I get the following error:
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer
at org.hibernate.type.ShortType.set(ShortType.java:40)
at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:83)
at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:60)
at org.hibernate.type.ManyToOneType.nullSafeSet(ManyToOneType.java:71)
Now if I change
Product product = (Product) session.load(Product.class, 1);
to
Product product = (Product) session.load(Product.class, (short) 1);
It all works fine. I'm assuming what's happening is that Hibernate is using the user provided key, which in the first scenario is an Integer, as the primary key and hence getting the CCE. My guess is that hibernate should be more pedantic about not trusting user provided values.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 6 months
[Hibernate-JIRA] Kommentiert: (HHH-1902) Alias Problem... Hibernate is replacing our alias at one place but not at another place
by MF (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1902?page=c... ]
MF commented on HHH-1902:
-------------------------
I found a workaround which at least seems to work in my case
http://forum.hibernate.org/viewtopic.php?p=2334698#2334698
However quite a few people will thank you if this bug will get fixed soon, I guess.
Thanks for your efforts, hibernate team!
> Alias Problem... Hibernate is replacing our alias at one place but not at another place
> ---------------------------------------------------------------------------------------
>
> Key: HHH-1902
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1902
> Project: Hibernate3
> Type: Bug
> Components: query-hql
> Versions: 3.0.3, 3.2.1
> Environment: Hibernate 3.0.3
> Database Platform : MSSQL Server 2000
> Reporter: Paras Dhawan
> Attachments: testhibernate.rar
>
>
> I have a query which contains a sub query in the select list... I have defined an alias of the sub query as _sqry1 now I am putting an Order By clause in the query.... Order By is on the result of the sub query and I have given the alias of the sub query in the Order By clause
> My Query is which i am giving to Hibernate is
> SELECT (SELECT SUM(_0_ServiceCharge_0_service.chargeAmount) FROM Service AS _0_service , ServiceCharge AS _0_ServiceCharge_0_service WHERE _transportService_Challan = _0_service AND _0_service = _0_ServiceCharge_0_service.service) AS _sqry1 FROM Challan AS _Challan LEFT OUTER JOIN _Challan.transportService AS _transportService_Challan ORDER BY _sqry1
> Now the problem is that Hibernate is replacing my aliases.... it replaced my alias of the sub query from _sqry1 to col_0_0_ .... it replaced this alias in the select list but not in the Order By clause... i.e. it replaced the alias where I defined it but it did not replaced the alias where I used it.... so the place where I am using the alias it is giving an error as undefined alias
> The generated SQL by Hibernate:
> select (select SUM(servicecha3_.ChargeAmount) from Services service2_, ServiceCharges servicecha3_ where transports1_.TransportServiceId=service2_.ServiceId and service2_.ServiceId=servicecha3_.serviceGroupTablePKId) as col_0_0_ from Challans challan0_ left outer join TransportServices transports1_ on challan0_.TransportServiceId=transports1_.TransportServiceId left outer join Services transports1_1_ on transports1_.TransportServiceId=transports1_1_.ServiceId order by _sqry1
> when I manually replaced my alias in the Order By clause then my query run successfully
> Either Hibernate should not replace my alias, even if it is replacing then it must replace all the occurences
> I cannot use criteria, I cannot use named queries, i cannot use native sql because my queries are formed at run time, I have to specify a HQL only... This is bug in Hibernate
> Hibernate version: 3.0.5
> Name and version of the database that I am using:
> MS SQL Server 2000
> Full stack trace of any exception that occurs:
> Exception in thread "main" org.hibernate.exception.SQLGrammarException: could not execute query
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.doList(Loader.java:2148)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
> at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
> at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1106)
> at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> at com.daffodilwoods.framework.utils.HibernateUtil.main(HibernateUtil.java:296)
> Caused by: java.sql.SQLException: [DataDirect][SQLServer JDBC Driver][SQLServer]Invalid column name '_sqry1'.
> at com.ddtek.jdbc.base.BaseExceptions.createException(Unknown Source)
> at com.ddtek.jdbc.base.BaseExceptions.getException(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRequest.processErrorToken(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRequest.processReplyToken(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRPCRequest.processReplyToken(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRequest.processReply(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRPCNonCursorExecuteRequest.submitPrepare(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRPCExecuteRequest.doPrepExec(Unknown Source)
> at com.ddtek.jdbc.sqlserver.tds.TDSRPCExecuteRequest.execute(Unknown Source)
> at com.ddtek.jdbc.sqlserver.SQLServerImplStatement.execute(Unknown Source)
> at com.ddtek.jdbc.base.BaseStatement.commonExecute(Unknown Source)
> at com.ddtek.jdbc.base.BaseStatement.executeQueryInternal(Unknown Source)
> at com.ddtek.jdbc.base.BasePreparedStatement.executeQuery(Unknown Source)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2145)
> ... 8 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 6 months
[Hibernate-JIRA] Commented: (HHH-198) Websphere transaction management with Hibernate
by Lakshmi (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-198?page=co... ]
Lakshmi commented on HHH-198:
-----------------------------
Does the status closed mean the CMT is supported on WAS6 ?
I am facing an issue on using WebsphereExtendedJTATransactionLookup with Hibernate,JbossCache and on WAS6.0. The link to the forum where the issue is posted is as follows.
http://forum.hibernate.org/viewtopic.php?t=968608
Briefly, I get an UnsupportedOperationException when introducing Jbosscache with Hibernate on WAS with CMT. If I use WebsphereTransactionmanagerLookup class instead, the exception is not seen. I do not if it is safe to use WebsphereTransactionManagerLookup meant for WAS5.1 on WAS6.0. Someone please clarify. I have tried the JTA jndi's mentioned in the previous comments, but it did not help.
I do not know the internals of JTA too well to be able to contribute a patch or so that is required. Kindly give some feedback on the problem seen.
> Websphere transaction management with Hibernate
> -----------------------------------------------
>
> Key: HHH-198
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-198
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.0 rc 1
> Environment: 1) Websphere Application developer 5.1.2 edition
> 2) Hibernate version: 2.1.6
> 3) Oracle 10g
> 4) Driver Oracle 10g XA thin driver (Managed Connection)
> Reporter: Cem Kayan
> Assignee: Gavin King
> Priority: Blocker
> Fix For: 3.0.1
> Attachments: HibernateWAS6.0.doc
>
>
> I'm trying to use Hibernate's transaction interface to lookup and use WebsphereTransactionManager.
> In my hibernate config files (at the moment i have two) ;
> i configured to initializeHibernateSessionFactories (both)
> there is a session facade calling a dao which are both SLSB's
> I'm using CMT
> SessionFacade : RequiresNew
> DAO: Mandatory
> during startup i have a HibernateException:
> (Could not obtain WebSphere JTSXA instance)
> Everthing else seems to be ok with my Wsad Server.
> for more details: http://forum.hibernate.org/viewtopic.php?t=935229&highlight=websphere
> I received following message from an IBM WAS Developers ;
> "The Hibernate code does not work on WebSphere Application Server 5.1.0.3 which you are running. It is using undocumented API and it is accessing the old 5.0 classes which are not present in 5.1 of WebSphere. It is trying to access a class JTSXA which does not exist in 5.1 You need to go back to the open source provider for a solution on this as this is not using the new classes in this undocumented internal api. "
> In Hibernate WebSphereTransactionManagerLookup class, there are three trials but in my case non of them is successfull.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 6 months
[Hibernate-JIRA] Closed: (HHH-1497) Allow interceptor for stateless session
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1497?page=all ]
Max Rydahl Andersen closed HHH-1497:
------------------------------------
Resolution: Duplicate
closing so we only have one issue open for it.
> Allow interceptor for stateless session
> ---------------------------------------
>
> Key: HHH-1497
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1497
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1.2
> Reporter: Stephen Friedrich
> Priority: Minor
>
>
> I need a way to adjust the sql that is executed in a stateless session.
> Currently the constructor of StatelessSessionImpl() always uses an empty interceptor.
> Is it possible to change that, so that there is an overloaded form of the constructor that allows to pass an interceptor
> (and overloaded methods in the session factory)?
> Here's my use case:
> I am doing mass inserts to a table using a stateless session.
> DB is postgres with table partitioning for this table. Postgres implements partitioning using inherited tables. There is no fully automated way to redirect data to the appropriate table 'partition'. It is possible with postgres to define either rules or triggers that insert data to the correct inherited table.
> However that was way too slow for me (and besides there were problems with postgres reporting back an inserted row count of zero which made hibernate complain).
> I made the changes mentioned above to hibernate and it worked very well (almost ten times faster).
> See also http://forum.hibernate.org/viewtopic.php?p=2292072
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 6 months
[Hibernate-JIRA] Commented: (HB-655) Oracle limitation: large "where x in (....)'
by Christian Gruber (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-655?page=com... ]
Christian Gruber commented on HB-655:
-------------------------------------
OK, but now, the new AST makes things easier, when I understood that correctly.
So your last comment is based on the fact "Environment: Hibernate 2.1.1". So, shall I create a new ticket with the new environment "Hibernate 3.2.0" in the HHH series, which still has the same defect?
Greetings,
Christian
> Oracle limitation: large "where x in (....)'
> --------------------------------------------
>
> Key: HB-655
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-655
> Project: Hibernate2
> Type: Improvement
> Components: core
> Versions: 2.1.1
> Environment: Hibernate 2.1.1
> Oracle 8i
> Reporter: Christian Gruber
> Assignee: Emmanuel Bernard
>
>
> Hello!
> There is a problem with queries with named parameters that consist of big lists with Oracle. An example:
> Collection idList = new LinkedList();
> for (int i=0; i<1001; i++) {
> idList.add(new Integer(i));
> }
> Query query = session.createQuery("from Geneticelem as geneticelem where geneticelem.id in (:ids)");
> query.setParameterList("ids", idList, Hibernate.INTEGER);
> Iterator geneticelems = query.iterate();
> This code results in an ORA-01795 exception, because not more than 1000 elements are allowed for "in".
> In OJB, this is solved by splitting the "in" condition is split up in chunks: http://db.apache.org/ojb/api/org/apache/ojb/broker/query/Criteria.html#ad...
> Can something like this also be implemented in Hibernate? I know, it's a limitation that will rarely be encountered, but still it's a limitation.
> Thanks,
> Christian
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 6 months
[Hibernate-JIRA] Commented: (HHH-1864) New dialect for Solid database for Hibernate 3.1.3 and Solid 4.5 onwards
by Chitrapandian N (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1864?page=c... ]
Chitrapandian N commented on HHH-1864:
--------------------------------------
Any progress or review to include/approve this to include it in the official distribution ?
> New dialect for Solid database for Hibernate 3.1.3 and Solid 4.5 onwards
> ------------------------------------------------------------------------
>
> Key: HHH-1864
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1864
> Project: Hibernate3
> Type: New Feature
> Components: core
> Environment: New dialect for Solid database for Hibernate 3.1.3 and Solid 4.5 onwards
> Reporter: Dave Richardson
> Attachments: SolidDialect.java
>
>
> I have written a Dialect class for the Solid database (www.solidtech.com) release 4.5 onwards.
> The SolidDialect is designed to be used with Solid release 4.5 or later.
> It does however work with Solid release 4.2 if the new features in Solid 4.5
> are not used. These are:
> - referential actions CASCADE, SET NULL, SET DEFAULT, RESTRICT and NO ACTION.
> - syntax for windowing over the result set: SELECT ... LIMIT ... OFFSET ...
> - new functions SOUNDEX() and DIFFERENCE() for approximate string comparisons.
> - automatic removing of constraints, with: DROP TABLE ... CASCADE CONSTRAINTS.
> I ran the Hibernate test suites with the SolidDialect using Hibernate 3.1.3.
> As a baseline I also ran the test suite against HSQLDB giving the following results:
> Tests: 806, unsuccessful: 12, success rate: 98.51%
> I had initially expected 100%, but the following comment from Gavin King in the
> Hibernate Forum explains the main reason:
> "There are some expected failures in the HB3 test suite.
> Basically, some obscure stuff that we broke going from HB2->HB3 and plan to fix "someday"."
> The results with the SolidDialect are:
> Tests: 806, unsuccessful: 36, success rate: 95.53%
> This compares reasonably well with HSQLDB.
> Note: some of the Hibernate tests rely on the availability of temporary tables.
> This is supported by Solid but requires an appropriate license (with support for so-called M-tables).
> I have sent the dialect and the results of the Hibernate test suite together with a detailed analysis of the results to Solid.
> They are currently analysing this information. If necessary I can provide a contact person at Solid.
> I hope the dialect can be included in an official distribution as soon as possible.
> Test Results Analysis
> =====================
> I analyzed the results and assigned the reason for failure to the following categories:
> - Feature not currently supported by the Solid database.
> - Error or non-standard behaviour in the Solid database engine and/or JDBC driver.
> - Error or missing support in the SolidDialect for Hibernate
> - Problem with the test case itself
> - Error in Hibernate itself.
> This led to the following:
> #ERRORS CATEGORY
> 11 Feature not supported by Solid
> 17 Probable Solid error or non-standard behaviour
> 0 Problem with SolidDialect
> 6 Problem with Hibernate test case
> 2 Hibernate bug
> 36 Total errors
> I patched three test cases and corrected one bug in Hibernate to acheive these results:
> hql.ASTParserLoadingTest:
> - changed query "from Animal where bodyWeight > 1e-38"
> to "from Animal where bodyWeight > 1e-12" since Solid supports a maximum
> precision of 16 and the precision is not the focus of the test.
> legacy.MasterDetailTest:
> - There are numerous dialect checks in this test. Many tests are omitted
> depending on the dialect. For MySQL the transaction isolation level
> is explicitly set for this test case.
> The test was patched to do this for Solid too.
> readonly.ReadOnlyTest:
> The test case initialises an attribute using:
> dp.setX( new BigDecimal( 0.1d ).setScale(19, BigDecimal.ROUND_DOWN) );
> Solid supports a maximum precision of 16.
> The test case was patched to use 12 instead of 19.
> Then only testReadOnlyOnProxiesFailureExpected failed later as it does with
> HSQLDB with the following diagnostic:
> org.hibernate.TransientObjectException: Instance was not associated with the session
> at org.hibernate.engine.StatefulPersistenceContext.setReadOnly(
> StatefulPersistenceContext.java:1095)
> at org.hibernate.impl.SessionImpl.setReadOnly(SessionImpl.java:1795)
> at org.hibernate.test.readonly.ReadOnlyTest.
> testReadOnlyOnProxiesFailureExpected(ReadOnlyTest.java:50)
> Research showed that this is a known bug (HHH-1352).
> I suppose I should submit separate patches for these modified test cases?
> The Hibernate bug corrected is in the statistics gathering class StatisticsImpl
> which under certain circumstances causes the test case stats.StatsTestestQueryStatGathering
> to fail with the following diagnostic:
> junit.framework.ComparisonFailure:
> expected:<from Continent> but was:<null>
> at org.hibernate.test.stats.StatsTest.testQueryStatGathering(StatsTest.java:136)
> I'll submit a separate patch for this.
> Here are now some details about the errors:
> Category: Feature not supported by Solid
> ----------------------------------------
> Of the 11 errors due to unsupported features, 6 are caused by functions in
> ORDER BY clauses and 3 by missing support for ResultSet.getBlob().
> A further error is caused by the test case joinedsubclass.JoinedSubclassTest
> which leads to the following SQL fragment:
> where (this_.address, this_.zip, this_.country) in ((?, ?, ?), (?, ?, ?))
> This is apparently not currently supported by Solid.
> Note: this test is skipped for HSQLDB, PostgreSQL, MySQL and DB2.
> The last error due to an unsupported feature occurs in the test case
> legacy.FooBarTest.testCollectionsInSelect
> The test issues the following HQL query:
> select count(*) from Bar as bar, bar.component.glarch.proxyArray as g
> where g.id in indices(bar.baz.fooArray)
> This leads to the following SQL fragment:
> ...and ((proxyarray2_.tha_key in(select fooarray4_.i from fooArray fooarray4_ where ...))
> Solid reports an exception (comparison between incompatible types).
> proxyarray2_.tha_key is of type VARCHAR(32) and fooarray4_.i is of type INTEGER.
> Some databases apparently support this comparison.
> Note: this test is skipped for HSQLDB, MySQL, DB2 and Oracle.
> Category: Problem with Hibernate test case
> ------------------------------------------
> Of the 6 errors 5 occur in the test hql.HQLTest producing the following diagnostics:
> Old query translator did not throw an exception, the new one did
> SQL is not the same as the old SQL
> New query translator did *NOT* throw an exception, the old one did
> This was not analyzed any further since the errors also occur with HSQLDB.
> The other error was in proxy.ProxyTest.testFullyLoadedPCSerialization
> which produced the following diagnostic:
> junit.framework.AssertionFailedError:
> unexpected DP delete count expected:<50> but was:<51>
> at org.hibernate.test.proxy.ProxyTest.testFullyLoadedPCSerialization(ProxyTest.java:291)
> This test also fails with HSQLDB with the same diagnostic.
> Possibly a problem with the test itself.
> Category: Hibernate bug
> -----------------------
> readonly.ReadOnlyTest.testReadOnlyOnProxiesFailureExpected fails as follows:
> org.hibernate.TransientObjectException:
> Instance was not associated with the session
> at org.hibernate.engine.StatefulPersistenceContext.setReadOnly(StatefulPersistenceContext.java:1095) at org.hibernate.impl.SessionImpl.setReadOnly(SessionImpl.java:1795)
> at org.hibernate.test.readonly.ReadOnlyTest.testReadOnlyOnProxiesFailureExpected(ReadOnlyTest.java:50)
> Research showed that this is a known bug (HHH-1352).
> legacy.SQLLoaderTest.testReturnPropertyComponentRename fails as follows:
> java.sql.SQLException: [Solid JDBC 04.50.0058] Column not found
> This test uses a native SQL query defined in the Hibernate mapping file:
> select id, nickName as n2, name, subName as otherSubName, subName1 from Componentizable
> The error is in Hibernate trying to access the result set using subName as the
> column name instead of the defined alias otherSubName.
> Research showed that this is a known bug (HHH-1515).
> I hope the dialect meets with your approval and look forward to it
> being included in the official distribution!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
17 years, 6 months