You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by "Janssen, Roger" <ro...@ibanx.nl> on 2008/01/30 15:45:28 UTC
BUGREPORT (more info availabe) : OJB 1.0.5 - count query in combination with IN-clause
Hi,
Been debugging some OJB code....
In class PersistenceBrokerImpl, in method OJBIterator
getRsIteratorFromQuery(Query query, ClassDescriptor cld,
RsIteratorFactory factory), in there this call is made:
query.preprocess(this);
However, the earlier classcastexception bug, learned us that we may have
enclosing queries as well, and the actual query is embedded in the
enclosing query. Looking at the EnclosingReportQuery class, we observe
that it does not implement the proper preprocess method that
preprocesses the embedded query. So we need to add that method to the
EnclosingReportQuery class (something like) :
/**
* @see
org.apache.ojb.broker.query.Query#preprocess(org.apache.ojb.broker.Persi
stenceBrokerInternal)
*/
public void preprocess(PersistenceBrokerInternal aPb)
{
// is this required???
super.preprocess(aPb);
// this one is!!!!
query.preprocess(aPb);
}
This way, calling the preprocess in the PersistenceBrokerImpl and in the
JdbcAccessImpl classes is covered for the EnclosingReportQuery as well.
But that is not all. Criteria may hold queries as well (subqueries).
Looking at the criteria implementations for IN-clauses en
EXISTS-clauses, I observe that both classes (InCriterion and
ExistsCriteria) do not implement proper preprocess-methods. So using
subqueries (in the way I described earlier with the IN-clause) will also
throw exceptions because of missing where clauses. So I think a
preprocess method should be added to those classes as well, something
like:
/**
* Preprocess the Criterion using a PersistenceBroker.
*
* @param aPb the PersistenceBroker
*/
public void preprocess(PersistenceBrokerInternal aPb)
{
if (getValue() instanceof Query)
{
((Query)getValue()).preprocess(aPb);
}
}
So, these were my thoughts. I do not know if I am completely correct, or
if I am missing some essential things.... But when I apply these patches
in combination with the earlier patch in BrokerHelper.... All the bugs
reagrding the count queries and the IN- and EXISTS-clauses are gone! In
my testsuite of our own persistencewrapper around OJB that is :).
Hope this helps.
I have some more exceptions in my testsuite but I am analyzing them.
When the cause is a bug in 1.0.5rc1, you'll hear.
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: BUGREPORT (more info availabe) : OJB 1.0.5 - count query in combination
with IN-clause
Posted by Armin Waibel <ar...@apache.org>.
Hi Roger,
I checked in your bug fix to SVN. The OJB test-suite pass without
failures (including two new count query tests relating to this bug).
regards,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: BUGREPORT (more info availabe) : OJB 1.0.5 - count query in combination
with IN-clause
Posted by Armin Waibel <ar...@apache.org>.
Hi Roger,
Janssen, Roger wrote:
> Hi,
>
> Been debugging some OJB code....
>
> In class PersistenceBrokerImpl, in method OJBIterator
> getRsIteratorFromQuery(Query query, ClassDescriptor cld,
> RsIteratorFactory factory), in there this call is made:
>
> query.preprocess(this);
>
>
> However, the earlier classcastexception bug, learned us that we may have
> enclosing queries as well, and the actual query is embedded in the
> enclosing query. Looking at the EnclosingReportQuery class, we observe
> that it does not implement the proper preprocess method that
> preprocesses the embedded query. So we need to add that method to the
> EnclosingReportQuery class (something like) :
>
> /**
> * @see
> org.apache.ojb.broker.query.Query#preprocess(org.apache.ojb.broker.Persi
> stenceBrokerInternal)
> */
> public void preprocess(PersistenceBrokerInternal aPb)
> {
> // is this required???
> super.preprocess(aPb);
>
> // this one is!!!!
> query.preprocess(aPb);
> }
>
> This way, calling the preprocess in the PersistenceBrokerImpl and in the
> JdbcAccessImpl classes is covered for the EnclosingReportQuery as well.
>
> But that is not all. Criteria may hold queries as well (subqueries).
> Looking at the criteria implementations for IN-clauses en
> EXISTS-clauses, I observe that both classes (InCriterion and
> ExistsCriteria) do not implement proper preprocess-methods. So using
> subqueries (in the way I described earlier with the IN-clause) will also
> throw exceptions because of missing where clauses. So I think a
> preprocess method should be added to those classes as well, something
> like:
>
> /**
> * Preprocess the Criterion using a PersistenceBroker.
> *
> * @param aPb the PersistenceBroker
> */
> public void preprocess(PersistenceBrokerInternal aPb)
> {
> if (getValue() instanceof Query)
> {
> ((Query)getValue()).preprocess(aPb);
> }
> }
>
> So, these were my thoughts. I do not know if I am completely correct, or
> if I am missing some essential things.... But when I apply these patches
> in combination with the earlier patch in BrokerHelper.... All the bugs
> reagrding the count queries and the IN- and EXISTS-clauses are gone! In
> my testsuite of our own persistencewrapper around OJB that is :).
>
> Hope this helps.
Yes, indeed! A brilliant analysis. I'm not very familiar with the query
stuff, so I will accept all of your suggestions and see what happens.
regards,
Armin
>
> I have some more exceptions in my testsuite but I am analyzing them.
> When the cause is a bug in 1.0.5rc1, you'll hear.
>
> 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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org