%SQL.FDW.Wrapper.XdbcWrapper

Handle of %XDBC package connection to some external database. This connection is used to prepare the SQL statement provided to this wrapper via the constructor's config object input.

Handle of a %XDBC package result set, used to loop over the result represented by this wraper. This property is populated upon the execute() method being called.

Handle of %XDBC package statement that is prepared and executed by this wrapper. This statement should be prepared during construction of the object to ensure availability of execute() and retrieval of metadata after object construction.

Inherited description: Constructor for wrappers that would like to receive SQL statements that potentially encapsulate pushed down query logic from the query that the corresponding foreign tables are involved in. The config object is a JSON object containing the standard 'server' and 'table' keys. For SQL wrappers, the wrapper execution should rely on the following special keys: { "sql": string, SQL text parameterized with ? "sqlParameters": array, contains subarrays where each subarray corresponds positionally to a ? parameter in the SQL text and represents information about that parameter. The subarrays are of the format [type, value] where type is an integer representing the data type of that parameter, in case relevant for binding, e.g. with Java setInt() etc binding methods. The type values are as follows: -7 : BOOLEAN -6 : TINYINT (1 byte) -5 : BIGINT 2 : NUMERIC 4 : INT (4 bytes) 5 : SMALLINT (2 bytes) 8 : DOUBLE, FLOAT, REAL 9 : DATE 10 : TIME 11 : TIMESTAMP 12 : VARCHAR (STRING) For example a query like: SELECT * FROM mytab WHERE myint = 10 AND mystring = 'cat' would, aftering being parameterized, receive a parameters argument of: [[4, 10], [12, "cat"]] }

Takes an array of arrays to bind to the SQL statement prepared for this wrapper.

If the error comes from the gateway this likely signals an error from the external database so augment the error message to make this fact clearer.

Inherited description: Clean up any associated structures and close this wrapper. This method is called automatically by %OnClose(), but may also be manually called prior to object deletion/going out of scope. This method should return a %Status value. Consider using status code $$$ForeignDataWrapperError when reporting custom error status messages.

Following this method call, next() will be ready to loop over the result set. We are basically building a wrapper around the XDBC result set.

Inherited description: Get the value at column index columnIndex for the current row. This should match the value in row(columnIndex). If the

Wrapper method to account for differing APIs in ODBC and JDBC result sets for getting multiple rows at once. ODBC utilizes GetMultipleRows() whereas JDBC utilizes GetBuffer(), which both return a $list of $lists. This method overridden by OdbcWrapper, so that the next() implementation can remain consistent between the two.

Dispatch to internal code to take the SQL Gateway Connection information and turn this into a connection object.

If a metadata object has yet to be constructed, we will do so upon the first call and then stash it. In such cases we will check if the XDBC Gateway metadata has already been gathered as this is what we will use to construct the wrapper metadata.

Using the prepared statement from this wrapper, get information about parameters involved in the statement that was prepared. Used by passthrough for the purposes of determining that the query was valid (we don't permit ? params in a THROUGH query).

This method grabs the next row available in this result and populates the multidimensional row property with it, as prescribed in %SQL.FDW.Wrapper.BaseWrapper. The overhead associated with method calls is non-negligible when aggregated over many rows. As such, instead of repeatedly calling Next() and GetData() on the %XDBC.Gateway.ResultSet object, we make use of that objects interface for returning an entire buffer of rows. The buffer is a $list of $list, where each internal $list is a row. This allows for one round trip to the Java code and also one round trip to the result set object for the entire fetch size. The interface for returning such a buffer (generally defined as a $list($lists()) representing rows) is different between JDBC and ODBC implementations of the XDBC gateway. As such, when getting a new buffer we call a local method that is overridden as necessary (e.g. by the OdbcWrapper). Since next() only returns one row at a time, we need to track some state in between calls in order to properly $listnext over the buffer. This is done with the bufferPointer property. The GetBuffer() method of the result set signals to us whether there are more buffers left after the current buffer, and thus lets us know whether we will need to call that method again in this future. This information is stored in the moreBuffersExists property. The buffer itself is stored in buffer. This method needs to take care of setting atEnd when the result set is exhausted and returns a boolean value accordingly when we have no more rows to return.

Reset the wrapper to be looped over again. Instead of using scrollable result sets that can be positioned at the beginning, it is easiest to just clean up the existing resources and then execute again. This method needs to also reset the state we store in the buffer-related properties used by next().

Inherited description: Given a %DynamicObject representing the server portion of a config object, validate that information contained in the object is sufficient for this wrapper to act upon. For example, if a wrapper requires the server to specify a "host" key, this method should validate that the serialized server information contains a relevant value: This method should return a %Status value. Consider using status code $$$ForeignDataWrapperError when reporting custom error status messages.

Inherited description: Given a %DynamicObject representing one table in the "tables" portion of a JSON config object, validate that information contained in the object is sufficient for this wrapper to act upon. For example, if a wrapper requires the tables to specify "table", this method should validate that the serialized table information contains a relevant value. This method should return a %Status value. Consider using status code $$$ForeignDataWrapperError when reporting custom error status messages.