AW: Mapping for type BIT broke afer upgrade from 1.0.1 to 1.0.4
Hi Armin, > Oliver Seimel wrote: > > Hi, > > > > we migrated from ojb 1.0.1 to 1.0.4 > > DB is Postgres. But I think, that the "problem" is > independent of the > > DB. > > We use the type BIT(1) for boolean values, so a mapping looks like > > this: > > > > > name="emailNotice" > > column="emailnotice" > > jdbc-type="BIT" > > /> > > > > With version 1.0.1 the generated SQL was ... WHERE > emailnotice = '1' > > . > > > > With version 1.0.4 the generated SQL is ... WHERE > emailnotice = 'true' > > . > > > > Thats not good, because the statement fails. > > > > Does anybody know why ojb now maps the BIT types to BOOLEAN? > > OJB 1.0.4 and higher try to support the JDBC 3.0 > specification which specify to map BIT to boolean > http://db.apache.org/ojb/docu/guides/jdbc-types.html > Maybe this cause your problem. > Could you please post the query/criteria which produce the > SQL shown above. Thanks for your response! here is an example: Criteria criteria = new Criteria(); criteria.addEqualTo("isCombination", new Boolean(true)); QueryByCriteria query = new QueryByCriteria(LicenseModule.class, criteria); licenses = broker.getCollectionByQuery(query); I changed it now to: criteria.addEqualTo("isCombination", new Integer(1)); p6spy log tells me that it is now correct: ...WHERE isCombination = '1' but I still get an exception: ...WHERE isCombination = ?' * Exception message is [ERROR: operator does not exist: bit = integer] This is strange at the first moment. I think OJB does everything right when I use new Integer instead of new Boolean (because of the p6spy log - and Postgres does accept the query of the log, if I use pgAdmin). The Postgres log says: LOG: statement: SELECT A0.licenseid,A0.class_name,A0.baselicenseid,A0.name,A0.iscombination FROM License A0 WHERE isCombination = $1 ERROR: operator does not exist: bit = integer HINT: No operator matches the given name and argument type(s). You may need to add explicit type casts. the message is clear, but as I said, at the moment I don't understand why Postgres does not accept the statement from ojb, but accepts it from pgadmin. (Probably it is the driver's fault?) So it seems it is not OJBs fault :) but I would be pleased if someone could give me a hint. Thanks Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mapping for type BIT broke afer upgrade from 1.0.1 to 1.0.4
Hi Oliver, Oliver Seimel wrote: Hi, we migrated from ojb 1.0.1 to 1.0.4 DB is Postgres. But I think, that the "problem" is independent of the DB. We use the type BIT(1) for boolean values, so a mapping looks like this: With version 1.0.1 the generated SQL was ... WHERE emailnotice = '1' . With version 1.0.4 the generated SQL is ... WHERE emailnotice = 'true' . Thats not good, because the statement fails. Does anybody know why ojb now maps the BIT types to BOOLEAN? OJB 1.0.4 and higher try to support the JDBC 3.0 specification which specify to map BIT to boolean http://db.apache.org/ojb/docu/guides/jdbc-types.html Maybe this cause your problem. Could you please post the query/criteria which produce the SQL shown above. regards, Armin Thank you very much Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BUGREPORT : OJB 1.0.5 release candidate 1 (unofficial)
Hi Roger, thanks for testing the upcoming 1.0.5 release. Janssen, Roger wrote: Hi, Like a reported earlier, something goes wrong with count queries. I can reproduce this bug (thanks for detailed description). When I hack some code in BrokerHelper, to get around the first bug (I don't know if what I do is correct, but I am trying): private Query getReportQueryByCriteriaCount(ReportQueryByCriteria aQuery) { Query cQuery = (Query) getQueryByCriteriaCount(aQuery); ReportQueryByCriteria countQuery = null; if(cQuery.getClass().isAssignableFrom(ReportQueryByCriteria.class)) { countQuery = (ReportQueryByCriteria) cQuery; } else { countQuery = (ReportQueryByCriteria)((EnclosingReportQuery) cQuery).getQuery(); } // BRJ: keep the original columns to build the Join countQuery.setJoinAttributes(aQuery.getAttributes()); // BRJ: we have to preserve groupby information Iterator iter = aQuery.getGroupBy().iterator(); while(iter.hasNext()) { countQuery.addGroupBy((FieldHelper) iter.next()); } return cQuery; } Then i do not get any class cast exceptions anymore. I tried the same solution a few minutes ago. This seems fix the bug - my local test to reproduce the bug pass and no new failures/error occur. But something is still fishy about the counts in combination with IN-clauses. It looks like the count query has lost its where clauses when I have IN-clauses in the query. ok, that's bad luck. I will try to reproduce this new problem too. regards, Armin [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: org.apache.ojb.broker.PersistenceBrokerSQLException: The root stack trace is --> * SQLException during execution of sql-statement: java.sql.SQLException: Not a condition in statement [select count(*) from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc] * sql statement: select count(*) from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc at org.hsqldb.jdbc.Util.throwError(Unknown Source) * Exception message: Not a condition in statement [select count(*) from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc] at org.hsqldb.jdbc.jdbcPreparedStatement.executeQuery(Unknown Source) * Vendor error code: -106 at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) * SQL state code: S1000 at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) ** at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source) at org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown Source) at org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknown Source) at org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown Source) at org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterator( Unknown Source) at org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery( Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIteratorF romQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIteratorB yQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source) at org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCount(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown Source) at org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterator( Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery( Unknown Source) Greetings, Roger Janssen iBanx * The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. --
Mapping for type BIT broke afer upgrade from 1.0.1 to 1.0.4
Hi, we migrated from ojb 1.0.1 to 1.0.4 DB is Postgres. But I think, that the "problem" is independent of the DB. We use the type BIT(1) for boolean values, so a mapping looks like this: With version 1.0.1 the generated SQL was ... WHERE emailnotice = '1' . With version 1.0.4 the generated SQL is ... WHERE emailnotice = 'true' . Thats not good, because the statement fails. Does anybody know why ojb now maps the BIT types to BOOLEAN? Thank you very much Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BUGREPORT : OJB 1.0.5 release candidate 1 (unofficial)
Hi, Like a reported earlier, something goes wrong with count queries. When I hack some code in BrokerHelper, to get around the first bug (I don't know if what I do is correct, but I am trying): private Query getReportQueryByCriteriaCount(ReportQueryByCriteria aQuery) { Query cQuery = (Query) getQueryByCriteriaCount(aQuery); ReportQueryByCriteria countQuery = null; if(cQuery.getClass().isAssignableFrom(ReportQueryByCriteria.class)) { countQuery = (ReportQueryByCriteria) cQuery; } else { countQuery = (ReportQueryByCriteria)((EnclosingReportQuery) cQuery).getQuery(); } // BRJ: keep the original columns to build the Join countQuery.setJoinAttributes(aQuery.getAttributes()); // BRJ: we have to preserve groupby information Iterator iter = aQuery.getGroupBy().iterator(); while(iter.hasNext()) { countQuery.addGroupBy((FieldHelper) iter.next()); } return cQuery; } Then i do not get any class cast exceptions anymore. But something is still fishy about the counts in combination with IN-clauses. It looks like the count query has lost its where clauses when I have IN-clauses in the query. [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: org.apache.ojb.broker.PersistenceBrokerSQLException: The root stack trace is --> * SQLException during execution of sql-statement: java.sql.SQLException: Not a condition in statement [select count(*) from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc] * sql statement: select count(*) from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc at org.hsqldb.jdbc.Util.throwError(Unknown Source) * Exception message: Not a condition in statement [select count(*) from (SELECT DISTINCT A0.ID FROM IBANX_PERMIT A0 WHERE null ) ojb_enc] at org.hsqldb.jdbc.jdbcPreparedStatement.executeQuery(Unknown Source) * Vendor error code: -106 at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) * SQL state code: S1000 at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) ** at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source) at org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown Source) at org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknown Source) at org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown Source) at org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterator( Unknown Source) at org.apache.ojb.broker.util.ExceptionHelper.generateException(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery( Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIteratorF romQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIteratorB yQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.(Unknown Source) at org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCount(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown Source) at org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterator( Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery( Unknown Source) Greetings, Roger Janssen iBanx * The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BUGREPORT : OJB 1.0.5 release candidate 1
Hi, Finally migrating away from 1.0rc6 to 1.0.5rc1 . :) Started migration our persistence layer around OJB, think a found a bug. When we create a reportquery and want to execute a count first, we get a ClassCastException. Caused by: java.lang.ClassCastException: org.apache.ojb.broker.query.EnclosingReportQuery at org.apache.ojb.broker.util.BrokerHelper.getReportQueryByCriteriaCount(Un known Source) at org.apache.ojb.broker.util.BrokerHelper.getCountQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCount(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCount(Unknown Source) Looking at the OJB source code: In BrokerHelper : Query getReportQueryByCriteriaCount(ReportQueryByCriteria aQuery) contains code : ReportQueryByCriteria countQuery = (ReportQueryByCriteria) getQueryByCriteriaCount(aQuery); In BrokerHelper : Query getQueryByCriteriaCount(QueryByCriteria aQuery) contains code : if (aQuery.isDistinct()) { countQuery.setDistinct(true); return new EnclosingReportQuery(countQuery, "count(*)"); } And class EnclosingReportQuery does not cast to ReportQueryByCriteria Hope this is enough info. Greetings, Roger Janssen iBanx * The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB 1.0.5 release candidate 1 (unofficial)
Hi Ilkka, Ilkka Priha wrote: Thanks Armin! Seems to work great with our app (MySQL-NT). Thanks for testing! The only found inconsistency with the previous version was that the default CopyStrategyImpl in ObjectCacheTwoLevelImpl is now final. We apply dynamic persistent Variables, which must be cloned during copying, and have implemented their special treatment in a subclass of CopyStrategyImpl. Now we have to copy the whole class instead of subclassing it to support both normal persistent objects and dynamic variables within the same strategy. Are there specific reasons to have a final copy strategy? Nope! Seems my code improvement goes over the top ;-) I will fix this and revert CopyStrategyImpl to a non-final class. regards, Armin Regards, Ilkka Armin Waibel wrote: Hi all, I have uploaded a first (unofficial) release candidate of the upcoming OJB 1.0.5 version. The source distribution can be found here: http://people.apache.org/~arminw/ Please give it a go and report any bugs. The source distribution contains a compiled OJB jar and the full html-documentation (of the upcoming 1.0.5). Further information can be found in the readme and release-notes files (recommended to read both files). If there are no bugs, I think 1.0.5 can be released within the next two or three weeks. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]