In ODSI 10gR3 fn:string-length() not pushing down to db (SR: 7714015.993)

Question

Under ALDSP 2.5, the following XQuery...
where string-length($medacf) = 0 or $medacf = $acf/column_name
...used to generate this SQL:
where ((? = 0) OR (? = t1."COLUMN_NAME"))
However, under ODSI 10gR3, the where clause is missing. Here's the query plan:
<?xml version="1.0"?>
<FLWOR>
<return>
<elementConstructor name="UserGroup" tip="{ld:PhysicalLayer/UserProfile/UserGroup}UserGroup">
<elementConstructor field="(0)" name="UserID" from="$f7815">
</elementConstructor>
<elementConstructor field="(1)" name="GroupID" from="$f7815">
</elementConstructor>
</elementConstructor>
</return>
<where sqlstop="Unable to generate SQL for XQuery expression: Cannot generate SQL for the function {http://www.bea.com/xquery/xquery-operators}integer-equal with parameters (Parameter,INTEGER), (Constant,INTEGER). There is no equivalent SQL for this function in general or with these particular parameter kinds/types. ">
<operator ns="op" name="boolean-or" tip="{http://www.w3.org/2004/07/xpath-operators}boolean-or">
<EQ sqlstop="Cannot generate SQL for the function {http://www.bea.com/xquery/xquery-operators}integer-equal with parameters (Parameter,INTEGER), (Constant,INTEGER). There is no equivalent SQL for this function in general or with these particular parameter kinds/types. " tip="{http://www.bea.com/xquery/xquery-operators}integer-equal">
<operator ns="fn" name="string-length" tip="{http://www.w3.org/2004/07/xpath-functions}string-length">
<variable name="__fparam0" kind="EXTERNAL">
</variable>
</operator>
<constant>
<![CDATA[[integer 0]]]>
</constant>
</EQ>
<EQ tip="{http://www.bea.com/xquery/xquery-operators}string-equal">
<variable name="__fparam0" kind="EXTERNAL">
</variable>
<variable name="(2)" from="$f7815" kind="extracted">
</variable>
</EQ>
</operator>
</where>
<for name="$f7815">
<source ns="fn-bea" name="UsrProfDataSource" sqlwarning="Generated SQL query does not have a WHERE clause. This may cause the query to take longer to finish and use excessive memory resources." kind="relational" tip="UsrProfDataSource">
<![CDATA[SELECT UPPER(t1."USER_ID") AS c1, t1."GRP_ID" AS c2, t1."USER_ID" AS c3
FROM "USRPROF"."USER_GRP" t1]]>
</source>
</for>
</FLWOR>

Answer 1

We have found that in ODSI 10gR3, the code pattern below is not pushed down if $logicalExpression is an expression that compares two atomic values and one of the values is a constant (used to work in ALDSP 2.5):
where $logicalExpression or $table/column = $input
Sample code that is not pushed down as expected:
where fn:string-length($accountNumber) _<= 0_ or $account/ACCT_NUM = $accountNumber
where fn:empty($accountNumber) or $accountNumber _= ''_ or $account/ACCT_NUM = $accountNumber
where fn:empty($clientId) or $clientId _= 0_ or $account/CLIENT_ID = $clientId
where fn:empty($effectiveDate) or $effectiveDate _= xs:date('0001-01-01')_ or $account/ACCT_EFF_DT = $effectiveDate
We have also found that a workaround is to tweak the code and replace $logicalExpression with something that can be pushed down and functionally equivalent (using fn:not, fn-bea:fence, fn:exactly-one, etc.).
Code that works:
where fn:not(fn:string-length($accountNumber) > 0) or $account/ACCT_NUM = $accountNumber
where fn-bea:fence(fn:string-length($accountNumber) <= 0) or $account/ACCT_NUM = $accountNumber
where fn:exactly-one(fn:string-length($accountNumber) <= 0) or $account/ACCT_NUM = $accountNumber
After examining the query plans, it appears to me (please correct me if any of these is not true):
- Comparators for atomic types ({http://www.bea.com/xquery/xquery-operators} integer-less-than-or-equal, string-equal, date-equal, etc.) are not pushed down if they are used to compare anything with a constant
- An "or" operation ({http://www.w3.org/2004/07/xpath-operators} boolean-or) is not pushed down if any of its operands cannot be pushed down
- fn:not, fn-bea:fence, and fn:exactly-one can be pushed down even if their operand cannot be pushed down
So the question is, why comparators are not pushed down when constants are involved? Is this a bug?
Thanks!
-r.