I have a SOAP driver I am working on. The SOAP API is hardcoded to only
return 1000 (default, 2000 max) values.
It uses a cookie style, like query-ex to get the next bit of the query.
I have <query> mapped to the SOAP query doc, and that works. The only
time I run into this issue of exceeding the 1000/2000 limit is on a migrate.
I would like to consider mapping to query-ex, since I sort of can do it.
The problem is, the first query into SOAP is a standard query, and if it
returns a cookie, then there is more data available. If not, there isn't.
So I added a rule Input transform to attach the
@attr-name="query-ex-support" to the _driver_identification_class_ query
response to tell the engine, that query-ex is support.
(My server just got moved into a firewalled network, and my 443 outbound
access is temporarily blocked, so I cannot test everything yet).
1) If query-ex is enabled, does the engine use it by default on migrate
requests? If so, I can handle it. Since I would just map query-ex to
be the special case.
2) My problem is a normal query, comes in as a <urn:query> doc. A paged
query comes in as the same, just to get the rest, you use a
<urn:queryMore> providing the cookie for the second to n values.
So if a <query> comes in for too much data, how do I provide the response?
If I return two query responses to every query, one as a query and one
as a query-ex doc, what would happen? Would the engine link the right
one, and reject the other? That is my first thought, dumb approach to