此内容没有您所选择的语言版本。
Chapter 2. JDBC compatibility
Data Virtualization provides a robust JDBC driver that implements most of the JDBC API according to the latest specification and compatible Java version. Most tooling designed to work with JDBC should work seamlessly with the Data Virtualization driver. When in doubt, see Incompatible JDBC Methods for functionality that has yet to be implemented.
If you’re needs go beyond JDBC, Data Virtualization has also provided JDBC Extensions for asynch handling, federation, and other features.
2.1. Generated Keys
Data Virtualization can return generated keys for JDBC sources and from Data Virtualization temp tables with SERIAL primary key columns. However the current implementation will return only the last set of keys generated and will return the key results directly from the source - no view projection of other intermediate handling is performed. For most scenarios (single source inserts) this handling is sufficient. A custom solution may need to be developed if you are using a FOR EACH ROW instead of trigger to process your inserts and target multiple tables that each return generated keys. It is possible to develop a UDF that also manipulates the returned generated keys - see the org.teiid.CommandContext
methods dealing with generated keys for more.
You cannot use Generated Keys when the JDBC Batched updates is used to insert the values into the source table.
2.2. Connecting to a Data Virtualization Server
The Data Virtualization JDBC API provides Java Database Connectivity (JDBC) access to a Virtual Database (VDB) deployed on Data Virtualization. The Data Virtualization JDBC API is compatible with the JDBC 4.0 specification; however, it is not compatible with some methods. You cannot use some advanced features, such as updatable result sets or SQL3 data types.
Java client applications connecting to a Data Virtualization Server will need to use at least the Java 1.8 JDK. Earlier versions of Java are not compatible. You may attempt to use a client driver from earlier Teiid versions that were compatible with the target JRE.
Once you have the VDB deployed in Data Virtualization, client applications can connect to the Data Virtualization Server and issue SQL queries against deployed VDB using JDBC API. If you are new to JDBC, see Java’s documentation about JDBC. Data Virtualization ships with teiid-1.3.0-jdbc.jar that can be found in the downloads.
You can also obtain the Data Virtualization JDBC from the Maven Repository https://oss.sonatype.org/content/repositories/releases/ using the coordinates:
<dependency> <groupId>org.teiid</groupId> <artifactId>teiid</artifactId> <classifier>jdbc</classifier> <version>1.3.0</version> </dependency>
Important classes in the client JAR:
-
org.teiid.jdbc.TeiidDriver
- allows JDBC connections using the DriverManager class. -
org.teiid.jdbc.TeiidDatasource
- allows JDBC connections using the DataSource XADataSource class. You should use this class to create managed or XA connections.
Once you have established a connection with the Data Virtualization Server, you can use standard JDBC API classes to interrogate metadata and execute queries.
2.2.1. OpenTracing compatibility
OpenTracing is optional for the client driver. For remote connections to propagate the span the driver must have the appropriate OpenTracing jars in its classpath. This can be done via a maven dependency:
<dependency> <groupId>io.opentracing</groupId> <artifactId>opentracing-util</artifactId> <version>${version.opentracing}</version> </dependency>
where version.opentracing (0.31 for Data Virtualization 11.0) is defined in the project integration bom.
Or you may manually include the opentracing-util, opentracing-api, and opentracing-noop jars as needed by the tooling or other environment where the Data Virtualization client jar is utilized.
OpenTracing support in the client and server requires that the respective runtimes have an appropriate tracing client installed and available via the GlobalTracer.
2.2.2. Driver Connection
Use org.teiid.jdbc.TeiidDriver as the driver class.
Use the following URL format for JDBC connections:
jdbc:teiid:<vdb-name>[@mm[s]://<host>:<port>][;prop-name=prop-value]*
The JDBC client will have both JRE and server compatibility considerations. Unless otherwise stated a client jar will typically be forward and backwards compatible with one major version of the server. You should attempt to keep the client up-to-date though as fixes and features are made on to the client.
URL Components
- <vdb-name> - Name of the VDB you are connecting to. Optionally VDB name can also contain version information inside it. For example: "myvdb.2", this is equivalent to supplying the "version=2" connection property defined below. However, use of vdb name in this format and the "version" property at the same time is not allowed.
- mm - defines Data Virtualization JDBC protocol, mms defines a secure channel (see SSL Client Connections for more)
- <host> - defines the server where the Data Virtualization Server is installed. If you are using IPv6 binding address as the host name, place it in square brackets. ex:[::1]
- <port> - defines the port on which the Data Virtualization Server is listening for incoming JDBC connections.
- [prop-name=prop-value] - additionally you can supply any number of name value pairs separated by semi-colon [;]. All compatible URL properties are defined in the connection properties section. Property values should be URL encoded if they contain reserved characters, e.g. (’?’, '=', ';', etc.)
2.2.2.1. Local Connections
To make a in-VM connection, omit the protocol and host/port: jdbc:teiid:vdb-name;props
2.2.2.2. URL Connection Properties
The following table shows all the connection properties that you can use with Data Virtualization JDBC Driver URL connection string, or on the Data Virtualization JDBC Data Source class.
Property Name | Type | Description |
---|---|---|
|
| Name of the client application; allows the administrator to identify the connections |
|
| Size of the resultset; The default size if 500. ⇐0 indicates that the default should be used. |
|
| Enable/disable partial results mode. Default false. See the Partial Results Mode section. |
|
| Only applies only when "autoCommit" is set to "true". This determines how a executed command needs to be transactionally wrapped inside the Data Virtualization engine to maintain the data integrity.
|
|
| If "true", the autoCommit setting, commit and rollback will be ignored for local transactions. Default false. |
|
| User name |
|
| Credential for user |
|
| Sets the parsing behavior for double quoted entries in SQL. The default, true, parses doubled quoted entries as identifiers. If set to false, then double quoted values that are valid string literals will be parsed as string literals. |
|
| Version number of the VDB |
|
| ResultSet caching is turned on/off. Default false. |
|
| If true, will automatically select a new server instance after a communication exception. Default false. This is typically not needed when connections are managed, as the connection can be purged from the pool. If true in embedded mode, connections will reconnect to a newer VDB of the same name/version. |
|
| (typically not set as a connection property) Can be ON, OFF,DEBUG;
|
|
| (typically not set as a connection property) Can be ON, OFF; ON prevents query execution, but parsing and planning will still occur. Default OFF. |
|
| Only applies to "local" connections. When this option is set to "true", then Data Virtualization looks for already authenticated security context on the calling thread. If one found it uses that users credentials to create session. Data Virtualization also verifies that the same user is using this connection during the life of the connection. if it finds a different security context on the calling thread, it switches the identity on the connection, if the new user is also eligible to log in to Data Virtualization otherwise connection fails to execute. |
|
| Only applies to "local" connections. When this option is set to "true" (the default), then the calling thread will be used to process the query. If false, then an engine thread will be used. |
|
|
Default query timeout in seconds. Must be >= 0. 0 indicates no timeout. Can be overriden by |
|
| A change was made in JDBC4 to return unaliased column names as the ResultSetMetadata column name. Prior to this, if a column alias were used it was returned as the column name. Setting this property to false will enable backwards compatibility with JDBC3 and earlier. Defaults to true. |
|
| JAAS configuration name. Only applies when configuring a GSS authentication. Defaults to Data Virtualization. See the Security Guide for configuration required for GSS. |
|
| Kerberos authenticated principle name. Only applies when configuring a GSS authentication. See the Security Guide for configuration required for GSS |
|
| Only applies to non-SSL socket connections. When "true" the request message and any associate payload will be encrypted using the connection cryptor. Default false. |
|
| In some situations tooling may choose undesirable fetch sizes for processing results. Set to true to disable honoring ResultSet.setFetchSize. Default false. |
|
| The login timeout in seconds. Must be >= 0. 0 indicates no specific timeout, but other timeouts may apply. If a connection cannot be created in approximately the the timeout value an exception will be thrown. A default of 0 does not mean that the login will wait indefinitely. Typically is an active vdb cannot be found the login will fail at that time. Local connections that specify a vdb version however can wait by default for up to org.teiid.clientVdbLoadTimeoutMillis. |
|
| If DatabaseMetaData will report Data Virtualization views as a VIEW table type. If false then Data Virtualization views will be reported as a TABLE. Default true. |
2.2.2.3. Client SSL Settings
The following sections define the properties required for each SSL mode. Note that when connecting to Data Virtualization Server with SSL enabled, you MUST use the "mms" protocol, instead of "mm" in the JDBC connection URL, for example
jdbc:teiid:<myVdb>@mms://<host>:<port>
There are two different sets of properties that a client can configure to enable 1-way or 2-way SSL.
2.2.2.3.1. Option 1: Java SSL properties
These are standard Java defined system properties to configure the SSL under any JVM, Data Virtualization is not unique in its use of SSL. Provide the following system properties to the client VM process.
1-way SSL
-Djavax.net.ssl.trustStore=<dir>/server.truststore (required) -Djavax.net.ssl.trustStorePassword=<password> (optional) -Djavax.net.ssl.keyStoreType (optional)
2-way SSL
-Djavax.net.ssl.keyStore=<dir>/client.keystore (required) -Djavax.net.ssl.keyStrorePassword=<password> (optional) -Djavax.net.ssl.trustStore=<dir>/server.truststore (required) -Djavax.net.ssl.trustStorePassword=<password> (optioanl) -Djavax.net.ssl.keyStroreType=<keystore type> (optional)
2.2.2.3.2. Option 2: Data Virtualization Specific Properties
Use this option when the above "javax" based properties are already in use by the host process. For example if your client application is a Tomcat process that is configured for https protocol and the above Java based properties are already in use, and importing Data Virtualization-specific certificate keys into those https certificate keystores is not allowed.
In this scenario, a different set of Data Virtualization-specific SSL properties can be set as system properties or defined inside the a "teiid-client-settings.properties" file. A sample "teiid-client-settings.properties" file can be found inside the "teiid-<version>-client.jar" file at the root called "teiid-client-settings.orig.properties". Extract this file, make a copy, change the property values required for the chosen SSL mode, and place this file in the client application’s classpath before the "teiid-<version>-client.jar" file.
SSL properties and definitions that can be set in a "teiid-client-settings.properties" file are shown below.
######################################## # SSL Settings ######################################## # # The key store type. Defaults to JKS # org.teiid.ssl.keyStoreType=JKS # # The key store algorithm, defaults to # the system property "ssl.TrustManagerFactory.algorithm" # #org.teiid.ssl.algorithm= # # The classpath or filesystem location of the # key store. # # This property is required only if performing 2-way # authentication that requires a specific private # key. # #org.teiid.ssl.keyStore= # # The key store password (not required) # #org.teiid.ssl.keyStorePassword= # # The key alias(not required, if given named certificate is used) # #org.teiid.ssl.keyAlias= # # The key password(not required, used if the key password is different than the keystore password) # #org.teiid.ssl.keyPassword= # # The classpath or filesystem location of the # trust store. # # This property is required if performing 1-way # authentication that requires trust not provided # by the system defaults. # #org.teiid.ssl.trustStore= # # The trust store password (not required) # #org.teiid.ssl.trustStorePassword= # # The cipher protocol, defaults to TLSv3 # org.teiid.ssl.protocol=TLSv1 # # Whether to allow anonymous SSL # (the TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite) # defaults to true # org.teiid.ssl.allowAnon=true # # Whether to allow trust all server certificates # defaults to false # #org.teiid.ssl.trustAll=false # # Whether to check for expired server certificates (no affect in anonymous mode or with trustAll=true) # defaults to false # #org.teiid.ssl.checkExpired=false
1-way SSL
org.teiid.ssl.trustStore=<dir>/server.truststore (required)
2-way SSL
org.teiid.ssl.keyStore=<dir>/client.keystore (required) org.teiid.ssl.trustStore=<dir>/server.truststore (required)
2.2.3. Additional Socket Client Settings
A "teiid-client-settings.properties" file can be used to configure Data Virtualization low level and SSL socket connection properties. Currently only a single properties file is expected per driver/classloader combination. A sample "teiid-client-settings.properties" file can be found inside the "teiid-<version>-client.jar" file at the root called "teiid-client-settings.orig.properties". To customize the settings, extract this file, make a copy, change the property values accordingly, and place this file in the client application’s classpath before the "teiid-<version>-client.jar" file. Typically clients will not need to adjust the non-SSL properties. For reference the properties are:
######################################## # Misc Socket Configuration ######################################## # # The time in milliseconds for socket timeouts. # Timeouts during the initialization, handshake, or # a server ping may be treated as an error. # # This is the lower bound for all other timeouts # the JDBC login timeout. # # Typically this should be left at the default of 1000 # (1 second). Setting this value too low may cause read # errors. # org.teiid.sockets.soTimeout=1000 # # Set the max time to live (in milliseconds) for non-execution # synchronous calls. # org.teiid.sockets.synchronousttl=240000 # # Set the socket receive buffer size (in bytes) # 0 indicates that the default socket setting will be used. # org.teiid.sockets.receiveBufferSize=0 # # Set the socket send buffer size (in bytes) # 0 indicates that the default socket setting will be used. # org.teiid.sockets.sendBufferSize=0 # # Set to true to enable Nagle's algorithm to conserve bandwidth # by minimizing the number of segments that are sent. # org.teiid.sockets.conserveBandwidth=false # # Maximum number of bytes per server message. # May need to be increased when using custom types and/or large batch sizes. # org.teiid.sockets.maxObjectSize=33554432
All properties listed in "teiid-client-settings.properties" can also be set as System or env properties.
2.3. Prepared Statements
Data Virtualization provides a standard implementation of java.sql.PreparedStatement
. PreparedStatements can be very important in speeding up common statement execution, since they allow the server to skip parsing, resolving, and planning of the statement. See the Java documentation for more information on PreparedStatement usage.
PreparedStatement
Considerations
-
It is not necessary to pool client side Data Virtualization
PreparedStatements
, since Data Virtualization performs plan caching on the server side. - The number of cached plans is configurable (see the Admin Guide), and are purged by the least recently used (LRU).
- Cached plans are not distributed through a cluster. A new plan must be created for each cluster member.
- Plans are cached for the entire VDB or for just a particular session. The scope of a plan is detected automatically based upon the functions evaluated during it’s planning process.
-
Stored procedures executed through a
CallableStatement
have their plans cached just as aPreparedStatement
. - Bind variable types in function signatures, e.g. "where t.col = abs(?)" can be determined if the function has only one signature or if the function is used in a predicate where the return type can be determined. In more complex situations it may be necessary to add a type hint with a cast or convert, e.g. upper(convert(?, string)).
If you have the same value of a binding repeated multiple times in your query, you can consolidate that usage in a couple of ways.
- The query can be enclosed as a anonymous procedure block:
BEGIN DECLARE string PARAM1 = cast(? as string); SELECT ... WHERE COLUMN1 = $1 AND COLUMN2 = $1 ...;
Note the cast of the bind variable, which is due to a small issue with the resolver that isn’t inferring the type from the variable declaration.
- You can also use the PostgreSQL like feature of $n positional bindings:
SELECT ... WHERE COLUMN1 = $1 AND COLUMN2 = $1 ...
2.4. ResultSet Limitations
The following limitations apply to result sets in Data Virtualization:
- TYPE_SCROLL_SENSITIVE are not compatible.
-
UPDATABLE
ResultSets are not compatible. - You cannot return multiple ResultSets from a Procedure execution.
2.5. JDBC Extensions
These are custom extensions to JDBC API from Data Virtualization to provide compatibility with various features.
2.5.1. Statement Extensions
The Data Virtualization statement extension interface, org.teiid.jdbc.TeiidStatement
, provides functionality beyond the JDBC standard. To use the extension interface, simply cast or unwap the statement returned by the Connection. The following methods are provided on the extension interface:
Method Name | Description |
---|---|
|
Get the query engine annotations if the statement was last executed with SHOWPLAN ON/DEBUG. Each |
| Get the debug log if the statement was last executed with SHOWPLAN DEBUG. |
| Get the current value of an execution property on this statement object. |
|
Get the query plan description if the statement was last executed with SHOWPLAN ON/DEBUG. The plan is a tree made up of |
| Get an identifier for the last command executed on this statement. If no command has been executed yet, null is returned. |
| Set the execution property on this statement. See the Execution Properties section for more information. It is generally preferable to use the SET Statement unless the execution property applies only to the statement being executed. |
| Set a per-command payload to pass to translators. Currently the only built-in use is for sending hints for Oracle data source. |
2.5.2. Partial Results Mode
You can use a "partial results" query mode with the Data Virtualization Server. In this mode, the behavior of the query processor changes so that the server returns results even when some data sources are unavailable.
For example, suppose that two data sources exist for different suppliers and your data designers have created a virtual group that creates a union between the information from the two suppliers. If your application submits a query without using partial results query mode and one of the suppliers’ databases is down, the query against the virtual group returns an exception. However, if your application runs the same query in "partial results" query mode, the server returns data from the running data source and no data from the data source that is down.
When using "partial results" mode, if a source throws an exception during processing it does not cause the user’s query to fail. Rather, that source is treated as returning no more rows after the failure point. Most commonly, that source will return 0 rows.
This behavior is most useful when using UNION
or OUTER JOIN
queries as these operations handle missing information in a useful way. Most other kinds of queries will simply return 0 rows to the user when used in partial results mode and the source is unavailable.
For each source that is excluded from the query, a warning will be generated describing the source and the failure. These warnings can be obtained from the Statement.getWarnings()
method. This method returns a SQLWarning
object but in the case of "partial results" warnings, this will be an object of type org.teiid.jdbc.PartialResultsWarning
class. This class can be used to obtain a list of all the failed sources by name and to obtain the specific exception thrown by each source.
Because Data Virtualization enables cursoring before an entire result is formed, it is possible that a data source failure will not be determined until after the first batch of results have been returned to the client. This can happen in the case of unions, but not joins. To ensure that all warnings have been accumulated, the statement should be checked after the entire result set has been read.
If other warnings are returned by execution, then the partial results warnings may occur after the first warning in the warning chain.
Partial results mode is off by default but can be turned on for all queries in a Connection with either setPartialResultsMode("true") on a DataSource or partialResultsMode=true on a JDBC URL. In either case, partial results mode may be toggled later with a SET Statement.
Setting Partial Results Mode
Statement statement = ...obtain statement from Connection... statement.execute("set partialResultsMode true");
Getting Partial Results Warnings
statement.execute("set partialResultsMode true"); ResultSet results = statement.executeQuery("SELECT Name FROM Accounts"); while (results.next()) { ... //process the result set } SQLWarning warning = statement.getWarnings(); while(warning != null) { if (warning instanceof PartialResultsWarning) { PartialResultsWarning partialWarning = (PartialResultsWarning)warning; Collection failedConnectors = partialWarning.getFailedConnectors(); Iterator iter = failedConnectors.iterator(); while(iter.hasNext()) { String connectorName = (String) iter.next(); SQLException connectorException = partialWarning.getConnectorException(connectorName); System.out.println(connectorName + ": " + connectorException.getMessage()); } } warning = warning.getNextWarning(); }
In some instances, typically JDBC sources, the source not being initially available will prevent Data Virtualization from automatically determining the appropriate set of source capabilities. If you get an exception indicating that the capabilities for an unavailable source are not valid in partial results mode, then it may be necessary to manually set the database version or similar property on the translator to ensure that the capabilities are known even if the source is not available.
2.5.3. Non-blocking Statement Execution
JDBC query execution can indefinitely block the calling thread when a statement is executed or a resultset is being iterated. In some situations you may not wish to have your calling threads held in these blocked states. When using embedded/local connections, you may optionally use the org.teiid.jdbc.TeiidStatement
and org.teiid.jdbc.TeiidPreparedStatement
interfaces to execute queries with a callback org.teiid.jdbc.StatementCallback
that will be notified of statement events, such as an available row, an exception, or completion. Your calling thread will be free to perform other work. The callback will be executed by an engine processing thread as needed. If your results processing is itself blocking and you want query processing to be concurrent with results processing, then your callback should implement onRow handling in a multi-threaded manner to allow the engine thread to continue.
Non-blocking Prepared Statement Execution
PreparedStatement stmt = c.prepareStatemen(sql); Data VirtualizationPreparedStatement tStmt = stmt.unwrap(Data VirtualizationPreparedStatement.class); tStmt.submitExecute(new StatementCallback() { @Override public void onRow(Statement s, ResultSet rs) { //any logic that accesses the current row ... System.out.println(rs.getString(1)); } @Override public void onException(Statement s, Exception e) throws Exception { s.close(); } @Override public void onComplete(Statement s) throws Exception { s.close(); }, new RequestOptions() });
The non-blocking logic is limited to statement execution only. Other JDBC operations, such as connection creation or batched executions do not yet have non-blocking options.
If you access forward positions in the onRow method (calling next, isLast, isAfterLast, absolute), they may not yet be valid and a org.teiid.jdbc.AsynchPositioningException
will be thrown. That exception is recoverable if caught or can be avoided by calling Data VirtualizationResultSet.available()
to determine if your desired positioning will be valid.
2.5.3.1. Continuous Execution
The RequestOptions
object may be used to specify a special type of continuous asynch execution via the continuous
or setContinuous
methods. In continuous mode the statement will be continuously re-executed. This is intended for consuming real-time or other data streams processed through a SQL plan. A continuous query will only terminate on an error or when the statement is explicitly closed. The SQL for a continuous query is no different than any other statement. Care should be taken to ensure that retrievals from non-continuous sources is appropriately cached for reuse, such as by using materialized views or session scoped temp tables.
A continuous query must do the following:
- return a result set
- be executed with a forward-only result set
- cannot be used in the scope of a transaction
Since resource consumption is expected to be different in a continuous plan, it does not count against the server max active plan limit. Typically custom sources will be used to provide data streams. See the Developer’s Guide, in particular the section on ReusableExecutions for more.
When the client wishes to end the continuous query, the Statement.close()
or Statement.cancel()
method should be called. Typically your callback will close whenever it no long needs to process results.
See also the ContinuousStatementCallback
for use as the StatementCallback
for additional methods related to continuous processing.
2.5.4. ResultSet Extensions
The Data Virtualization result set extension interface, org.teiid.jdbc.TeiidResultSet
, provides functionality beyond the JDBC standard. To use the extension interface, simply cast or unwap a result set returned by a Data Virtualization statement. The following methods are provided on the extension interface:
Method Name | Description |
---|---|
| Returns an estimate of the minimum number of rows that can be read (after the current) without blocking or the end of the ResultSet is reached. |
2.5.5. Connection Extensions
Data Virtualization connections (defined by the org.teiid.jdbc.TeiidConnection
interface) are compatible with the changeUser method to reauthenticate a given connection. If the reauthentication is successful the current connection my be used with the given identity. Existing statements/result sets are still available for use under the old identity.
2.6. Incompatible JDBC Methods
Based upon the JDBC in JDK 1.6, this appendix details only those JDBC methods that Data Virtualization is not compatible with. Unless specified below, Data Virtualization is compatible with all other JDBC Methods.
Those methods listed without comments throw a SQLException stating that it is not supported.
Where specified, some listed methods do not throw an exception, but possibly exhibit unexpected behavior. If no arguments are specified, then all related (overridden) methods are not compatible. If an argument is listed then only those forms of the method specified are not compatible.
2.6.1. Incompatible Classes and Methods in "java.sql"
Class name | Methods |
---|---|
| [source,java] ---- getBinaryStream(long, long) - throws SQLFeatureNotSupportedException setBinaryStream(long) - - throws SQLFeatureNotSupportedException setBytes - - throws SQLFeatureNotSupportedException truncate(long) - throws SQLFeatureNotSupportedException ---- |
| [source,java] ---- getObject(int parameterIndex, Map<String, Class<?>> map) - throws SQLFeatureNotSupportedException getRef - throws SQLFeatureNotSupportedException getRowId - throws SQLFeatureNotSupportedException getURL(String parameterName) - throws SQLFeatureNotSupportedException registerOutParameter - ignores registerOutParameter(String parameterName, *) - throws SQLFeatureNotSupportedException setRowId(String parameterName, RowId x) - throws SQLFeatureNotSupportedException setURL(String parameterName, URL val) - throws SQLFeatureNotSupportedException ---- |
| [source,java] ---- getCharacterStream(long arg0, long arg1) - throws SQLFeatureNotSupportedException setAsciiStream(long arg0) - throws SQLFeatureNotSupportedException setCharacterStream(long arg0) - throws SQLFeatureNotSupportedException setString - throws SQLFeatureNotSupportedException truncate - throws SQLFeatureNotSupportedException ---- |
| [source,java] ---- createBlob - throws SQLFeatureNotSupportedException createClob - throws SQLFeatureNotSupportedException createNClob - throws SQLFeatureNotSupportedException createSQLXML - throws SQLFeatureNotSupportedException createStruct(String typeName, Object[] attributes) - throws SQLFeatureNotSupportedException getClientInfo - throws SQLFeatureNotSupportedException releaseSavepoint - throws SQLFeatureNotSupportedException rollback(Savepoint savepoint) - throws SQLFeatureNotSupportedException setHoldability - throws SQLFeatureNotSupportedException setSavepoint - throws SQLFeatureNotSupportedException setTypeMap - throws SQLFeatureNotSupportedException setRealOnly - effectively ignored ---- |
| [source,java] ---- getAttributes - throws SQLFeatureNotSupportedException getClientInfoProperties - throws SQLFeatureNotSupportedException getRowIdLifetime - throws SQLFeatureNotSupportedException ---- |
|
|
| [source,java] ---- setRef - throws SQLFeatureNotSupportedException setRowId - throws SQLFeatureNotSupportedException setUnicodeStream - throws SQLFeatureNotSupportedException ---- |
|
|
| [source,java] ---- deleteRow - throws SQLFeatureNotSupportedException getHoldability - throws SQLFeatureNotSupportedException getObject(, Map<String, Class<?>> map) - throws SQLFeatureNotSupportedException getRef - throws SQLFeatureNotSupportedException getRowId - throws SQLFeatureNotSupportedException getUnicodeStream - throws SQLFeatureNotSupportedException getURL - throws SQLFeatureNotSupportedException insertRow - throws SQLFeatureNotSupportedException moveToInsertRow - throws SQLFeatureNotSupportedException refreshRow - throws SQLFeatureNotSupportedException rowDeleted - throws SQLFeatureNotSupportedException rowInserted - throws SQLFeatureNotSupportedException rowUpdated - throws SQLFeatureNotSupportedException setFetchDirection - throws SQLFeatureNotSupportedException update - throws SQLFeatureNotSupportedException ---- |
|
|
|
|
|
|
|
|
|
|
2.6.2. Incompatible Classes and Methods in "javax.sql"
Class name | Methods |
---|---|
|
|