Query Slicer logic will enable the adapter to push down separate requests for each filter value using the IN clause.

This enables the adapter to avoid client side filtering.

Setting up Query Slicer Logic

Open the RSD where Query Slicer logic will be implemented.

See the example apiscript below. This will need to be used with a restadoGet operation instead of an XML/JSON operation.

<api:info title="queryslicer" desc="Generated schema file." other:queryslicercolumn="flight_number2222" xmlns:other="http://apiscript.com/ns?v1">

<attr name="flight_number2222"                   xs:type="integer"  readonly="false"              other:xPath="/json/flight_number"   other:filter="{flight_number2222}"  />

<api:check attr="_input.flight_number2222">
<api:set attr="uri" value="[uri]?flight_number={flight_number2222}"/>

With this configuration, the following query will now dynamically pass down separate requests for each filter value:

SELECT * FROM launches WHERE flight_number2222 IN ('1', '2', '3')

Additionally, you can use a sub-SELECT query in the filter to pass a dynamic list of filters:

SELECT * FROM launches WHERE flight_number2222 IN (SELECT flightId IN flights)

In order for this function to work, you need to set other:queryslicercolumn="flight_number2222" in the child table's RSD only.

Limits and Considerations

In a script, most of the places that access a sliced input will not return single elements. For example, if you do something like this within your GET block trying to access the sliced value of the ID field:

<api:set attr="URI" value="http://example.com/[_input.id]" />

This won't work and will give you back a URL containing the full SQL list (e.g. http://example.com/(1, 2, 3)) instead of just a single ID.

The only place in the script that you can use sliced IDs is in URIs, because the brace bits are expanded at a later stage where the sliced input is actually available:

<api:set attr="URI" value="http://example.com/{id}" />