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]
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]
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]
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]
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.
--
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]
