DB Adapter Query - Polling using nested select

Question

When polling a table to initiate a BPEL process, can I use a nested select in the expression.

Answer 1

The visual expression builder does not currently support this so you need to specify the raw sql directly.
If you use the DeletePollingStrategy there is a way you can specify the exact sql string for both the 'select' and the after read 'delete'. So if you write the where clause yourself it can contain nested selects.
This is the readme from the new PureSQLSelect database adapter sample. Also you may want to look at the PureSQLPolling sample.
This sample shows you how you can bypass the designer's visual where clause builder to specify arbitrarily complex sql strings for your selects.
Like the other samples, this sample uses the basic Movies schema.
The Steps:
Create a basic select. Made sure it has the same name and number of input parameters as you will need for your sql string. In this case create a single input parameter and call it 'genre_param'.
Create a trivial where clause in the wizard expression builder using genre_param. I.e. genre.like(genre_param)
Ideally run the sample once just to make sure everything else works and to get a template SQL. The select ... FROM ... part will be the same.
Open the toplink_mappings.xml file. Look for an element called <database-query>. There will likely only be one. A sample is presented here:
<query-manager>
<descriptor-query-manager>
<existence-check>Check cache</existence-check>
<descriptor-named-queries>
<database-query>
<query-name>selectByGenreSelect</query-name>
<query-should-maintain-cache>true</query-should-maintain-cache>
<cascade-policy>1</cascade-policy>
<should-bind-all-parameters>undefined</should-bind-all-parameters>
<should-cache-statement>undefined</should-cache-statement>
<should-use-wrapper-policy>true</should-use-wrapper-policy>
<query-timeout>0</query-timeout>
<query-arguments>
<string>genre_param</string>
</query-arguments>
<query-argument-types>
<values>java.lang.String</values>
</query-argument-types>
<reference-class>PureSQLSelect.Movies</reference-class>
<refresh-identity-map>false</refresh-identity-map>
<cache-usage>2</cache-usage>
<lock-mode>0</lock-mode>
<distinct-state>0</distinct-state>
<query-indirection>
<in-memory-query-indirection>
<policy>0</policy>
</in-memory-query-indirection>
</query-indirection>
<main-expression>
<expression>
<operator-type>AND</operator-type>
<expression-list>
<expression>
<operator-type>Like</operator-type>
<first-argument>
<argument>
<query-key-name>genre</query-key-name>
<outer-join>false</outer-join>
<to-many>false</to-many>
<argument-class>oracle.toplink.tools.workbench.expressions.QueryableArgumentRepresentation</argument-class>
</argument>
</first-argument>
<second-argument>
<argument>
<parameter-name>genre_param</parameter-name>
<argument-class>oracle.toplink.tools.workbench.expressions.ParameterArgumentRepresentation</argument-class>
</argument>
</second-argument>
<expression-class>oracle.toplink.tools.workbench.expressions.BinaryExpressionRepresentation</expression-class>
</expression>
</expression-list>
<expression-class>oracle.toplink.tools.workbench.expressions.CompoundExpressionRepresentation</expression-class>
</expression>
</main-expression>
<type>oracle.toplink.queryframework.ReadAllQuery</type>
</database-query>
</descriptor-named-queries>
</descriptor-query-manager>
</query-manager>
We want to switch this query from using a high-level expression to a pure sql string. You will remove the <main-expression> element and replace it with a <sql-string> element of your own devising.
Your replacement should look something like this:
<query-manager>
<descriptor-query-manager>
<existence-check>Check cache</existence-check>
<descriptor-named-queries>
<database-query>
<query-name>selectByGenreSelect</query-name>
<query-should-maintain-cache>true</query-should-maintain-cache>
<cascade-policy>1</cascade-policy>
<should-bind-all-parameters>undefined</should-bind-all-parameters>
<should-cache-statement>undefined</should-cache-statement>
<should-use-wrapper-policy>true</should-use-wrapper-policy>
<query-timeout>0</query-timeout>
<sql-string>SELECT DELETED, DIRECTOR, GENRE, LAST_UPDATED, RATED, RATING, RELEASE_DATE, RUN_TIME, SEQUENCENO, STARRING, STATUS, SYNOPSIS, TITLE, TOTAL_GROSS, VIEWER_RATING FROM MOVIES WHERE (upper(GENRE) LIKE upper(concat(concat('%', #genre_param), '%'))) ORDER BY TOTAL_GROSS desc</sql-string>
<query-arguments>
<string>genre_param</string>
</query-arguments>
<query-argument-types>
<values>java.lang.String</values>
</query-argument-types>
<reference-class>PureSQLSelect.Movies</reference-class>
<refresh-identity-map>false</refresh-identity-map>
<cache-usage>2</cache-usage>
<lock-mode>0</lock-mode>
<distinct-state>0</distinct-state>
<query-indirection>
<in-memory-query-indirection>
<policy>0</policy>
</in-memory-query-indirection>
</query-indirection>
<type>oracle.toplink.queryframework.ReadAllQuery</type>
</database-query>
</descriptor-named-queries>
</descriptor-query-manager>
</query-manager>
Gotchas:
The tempation to start writing pure sql may be terrible to some, but it was intentionally left out of the wizard for good reasons. Please be wary of the following when specifying pure sql:
-There is a way to set the pure sql string in the Mapping Workbench, but when you edit the partnerlink to refresh the toplink_mappings.xml you may get an exception due to the query being in a pure sql format. For this reason you need to manually edit the toplink_mappings.xml, and again every time your run the wizard and hit finish after that.
-The #genre_param is a TopLink convention for writing a sql string which still takes parameters. At runtime if you enter 'Action' in the bpel console, you will see this sql:
SELECT DELETED, DIRECTOR, GENRE, LAST_UPDATED, RATED, RATING, RELEASE_DATE, RUN_TIME, SEQUENCENO, STARRING, STATUS, SYNOPSIS, TITLE, TOTAL_GROSS, VIEWER_RATING FROM SYSTEM.MOVIES WHERE (GENRE LIKE ?)
bind => [Action]
The #genre_param gets replaced with the value of the input parameter genre_param.
-When specifying pure sql you should be aware of the following:
-maintenance issues
-loss of database platform independence
-The sql needs to conform with the way TopLink works. It is recommended that you do not change the SELECT ... FROM ... part of the query. TopLink's design is to read from one table at a time. If an Employee has an Address, then the Address is read with a hidden relationship query. There are two advanced TopLink features which optimize reading from multiple tables, called joinedAttribute and batchAttribute reading, but the combination of these features with raw sql was not explored here. So to avoid danger you can only really affect the top level query, and only rewrite the where clause.
-The pure sql route does not interact with most TopLink features, especially batch reading (on by default), and can not be combined with the following:
-LogicalDeletePollingStrategy
-SequencingPollingStrategy (LastUpdated, LastReadId, File)
These features extend the selection criteria at runtime.