db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: Bug in org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement
Date Wed, 28 Jul 2004 18:40:24 GMT
Is this in 1.0.1 as well? We can roll it into the upcoming release  
really easily.

-Brian

On Jul 28, 2004, at 2:12 PM, Jakob Braeuchi wrote:

> hi lasse,
>
> i commit the fix and added two testcases (QueryTest#testEmptyORed,  
> QueryTest#testEmptyANDed).
>
> hth
> jakob
>
> Jakob Braeuchi schrieb:
>
>> hi lasse,
>> thanks for reporting this problem.
>> the fix is imo much simpler:
>>                 Criteria pc = (Criteria) o;
>>                 if (pc.isEmpty())
>>                 {
>>                     continue;    //skip empty criteria
>>                 }
>> i'll add a testcase and the fix asap.
>> jakob
>> lasse.lambrecht@allianz.de schrieb:
>>> Hi,
>>>
>>> I am encountering a problem after upgrading to OJB 1.0 recently.
>>> In our application we've a situation where we add an empty criteria  
>>> object
>>> to another using the addOrCriteria-Method.
>>> This results in a weird SQL like this one, that doesn't work because  
>>> of the
>>> nulls:
>>>
>>> SELECT
>>> A0.ZEITSTEMPEL,A0.BEARBEITER_NR,A0.MELDUNG_NR,A0.PRIORITAET,A0.BEN_NR 
>>> ,A0.ART_NR,A0.MELDUNG,A0.OBJEKT_VERSION,A0.BETREFF
>>>  FROM LSVERFT.MELDUNGEN A0 WHERE ( null OR  (null)) AND  (A0.ART_NR  
>>> < ?)
>>>
>>> I had no problems with that so far, using RC5.
>>> The point seems to be that (in CVS) from Version 1.37 to 1.38 in
>>> o.a.o.b.q.Criteria.addOrCriteria(...) the pc.setType(NONE) call  
>>> changed to
>>> pc.setType(OR).
>>> With that, the o.a.o.b.a.s.SqlQueryStatement.asSQLStatement(Criteria  
>>> crit)
>>> now returns a String containing "null" for such an empty criteria.  
>>> In the
>>> examples above there were two empty criterias, therefore two nulls.
>>>
>>> As a solution, I fixed the SqlQueryStatement.asSQLStatement(Criteria  
>>> crit)
>>> to scan the result of the recursive call first, before adding the  
>>> result as
>>> a String to the SQL statement. Like this:
>>>
>>>                         switch (pc.getType()) {
>>>                               case (Criteria.OR) :
>>>                                     {
>>>                                           // null is returned if the
>>> criteria is empty
>>>                                           String sqlFragment =
>>> asSQLStatement(pc);
>>>                                           if (sqlFragment != null) {
>>>                                                 if  
>>> (statement.length() > 0)
>>> {
>>>                                                        
>>> statement.append(" OR
>>> ");
>>>                                                 }
>>>
>>> statement.append(addAtStart);
>>>
>>> statement.append(sqlFragment);
>>>                                                  
>>> statement.append(addAtEnd);
>>>                                           }
>>>                                           break;
>>>                                     }
>>>                               case (Criteria.AND) :
>>>                                     {
>>>                                           // null is returned if the
>>> criteria is empty
>>>                                           String sqlFragment =
>>> asSQLStatement(pc);
>>>                                           if (sqlFragment != null) {
>>>                                                 if  
>>> (statement.length() > 0)
>>> {
>>>                                                        
>>> statement.insert(0, "
>>> ( ");
>>>                                                        
>>> statement.append(")
>>> AND ");
>>>                                                 }
>>>
>>> statement.append(addAtStart);
>>>
>>> statement.append(sqlFragment);
>>>                                                  
>>> statement.append(addAtEnd);
>>>                                           }
>>>                                           break;
>>>                                     }
>>>                         }
>>>
>>> Sure, I can handle that in my application, not to add an empty  
>>> Criteria
>>> object. But OJB shouldn't create an invalid SQL anyway.
>>>
>>> Regards
>>> Lasse
>>> ___
>>>
>>>
>>>> Lasse Lambrecht
>>>> Allianz Lebensversicherungs-AG
>>>> IS-LF1 K6, Produktdatenbank
>>>> +49 711 663 5412  #  1021-5412
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message