| Home >> All >> org >> springframework >> [ jdbc Javadoc ] |
| • | org.springframework.jdbc.core.* (38) | • | org.springframework.jdbc.datasource.* (15) |
| • | org.springframework.jdbc.object.* (11) | • | org.springframework.jdbc.support.* (39) |
• org.springframework.jdbc: Javadoc index of package org.springframework.jdbc.
Package Samples:
• org.springframework.jdbc.core.support: Provides the core JDBC framework, based on JdbcTemplate and its associated callback interfaces and helper objects.
• org.springframework.jdbc.support.rowset: Support classes for the JDBC framework, used by the classes in the jdbc.core and jdbc.object packages.
• org.springframework.jdbc.support: The classes in this package make JDBC easier to use and reduce the likelihood of common errors.
• org.springframework.jdbc.core
• org.springframework.jdbc.datasource
• org.springframework.jdbc.object
• org.springframework.jdbc.support.incrementer
• org.springframework.jdbc.support.lob
• org.springframework.jdbc.support.nativejdbc
Classes:
• LazyConnectionDataSourceProxy: Proxy for a target DataSource, fetching actual JDBC Connections lazily, i.e. not until first creation of a Statement. Connection initialization properties like auto-commit mode, transaction isolation and read-only mode will be kept and applied to the actual JDBC Connection as soon as an actual Connection is fetched (if ever). Consequently, commit and rollback calls will be ignored if no Statements have been created. This DataSource proxy allows to avoid fetching JDBC Connections from a pool unless actually necessary. JDBC transaction control can happen without fetching a Connection from the pool ...
• SimpleNativeJdbcExtractor: Simple implementation of the NativeJdbcExtractor interface. Assumes a pool that wraps Connection handles but not DatabaseMetaData: In this case, the underlying native Connection can be retrieved by simply calling conHandle.getMetaData().getConnection() . All other JDBC objects will be returned as passed in. This extractor should work with any pool that does not wrap DatabaseMetaData, and will also work with any plain JDBC driver. Note that a pool can still wrap Statements, PreparedStatements, etc: The only requirement of this extractor is that java.sql.DatabaseMetaData does not get wrapped, returning ...
• DataSourceTransactionManager: PlatformTransactionManager implementation for a single JDBC DataSource. Binds a JDBC Connection from the specified DataSource to the thread, potentially allowing for one thread Connection per DataSource. Application code is required to retrieve the JDBC Connection via DataSourceUtils.getConnection(DataSource) instead of J2EE's standard DataSource.getConnection() . This is recommended anyway, as it throws unchecked org.springframework.dao exceptions instead of checked SQLException. All framework classes like JdbcTemplate use this strategy implicitly. If not used with this transaction manager, the ...
• TransactionAwareDataSourceProxy: Proxy for a target DataSource, adding awareness of Spring-managed transactions. Similar to a transactional JNDI DataSource as provided by a J2EE server. Data access code that should remain unaware of Spring's data access support can work with this proxy to seamlessly participate in Spring-managed transactions. Note that the transaction manager, for example DataSourceTransactionManager, still needs to work with underlying DataSource, not with this proxy. Make sure that TransactionAwareDataSourceProxy is the outermost DataSource of a chain of DataSource proxies/adapters. TransactionAwareDataSourceProxy ...
• NativeJdbcExtractor: Interface for extracting native JDBC objects from wrapped objects coming from connection pools. This is necessary to be able to case to native implementations like OracleConnection or OracleResultSet in application code, for example to create Blobs or access other vendor-specific features. Note: Setting a custom NativeJdbcExtractor is just necessary if you want to cast to database-specific implementations, like OracleConnection/OracleResultSet. Else, any wrapped JDBC object will be fine. Note: To be able to support any pool's strategy of native ResultSet wrapping, it is advisable to get both the ...
• LobHandler: Abstraction for handling large binary fields and large text fields in specific databases, no matter if represented as simple types or Large OBjects. Its main purpose is to isolate Oracle's peculiar handling of LOBs in OracleLobHandler; most other databases should work with DefaultLobHandler. Provides accessor methods for BLOBs and CLOBs, and acts as factory for LobCreator instances, to be used as sessions for creating BLOBs or CLOBs. LobCreators are typically instantiated for each statement execution or for each transaction. They are not thread-safe because they might track allocated database resources ...
• UserCredentialsDataSourceAdapter: An adapter for a target DataSource, applying the given user credentials to every standard getConnection() call, that is, implicitly invoking getConnection(username, password) on the target. All other methods simply delegate to the corresponding methods of the target DataSource. Can be used to proxy a target JNDI DataSource that does not have user credentials configured. Client code can work with the DataSource without passing in username and password on every getConnection() call. In the following example, client code can simply transparently work with the preconfigured "myDataSource", implicitly ...
• JdbcTemplate: This is the central class in the JDBC core package. It simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results. This class executes SQL queries or updates, initiating iteration over ResultSets and catching JDBC exceptions and translating them to the generic, more informative exception hierarchy defined in the org.springframework.dao package. Code using this class need only implement callback interfaces, giving them a clearly defined contract. The PreparedStatementCreator callback interface creates a ...
• OracleLobHandler: LobHandler implementation for Oracle databases. Uses proprietary API to create oracle.sql.BLOB and oracle.sql.CLOB instances, as necessary when working with Oracle's JDBC driver. Developed and tested on Oracle 9i. While most databases are able to work with DefaultLobHandler, Oracle just accepts Blob/Clob instances created via its own proprietary BLOB/CLOB API, and additionally doesn't accept large streams for PreparedStatement's corresponding setter methods. Therefore, you need to use a strategy like this LobHandler implementation. Needs to work on a native JDBC Connection, to be able to cast it ...
• DriverManagerDataSource: Simple implementation of the standard JDBC DataSource interface, configuring a plain old JDBC Driver via bean properties, and returning a new Connection for every getConnection call. Useful for test or standalone environments outside of a J2EE container, either as a DataSource bean in a respective ApplicationContext, or in conjunction with a simple JNDI environment. Pool-assuming Connection.close() calls will simply close the Connection, so any DataSource-aware persistence code should work. In a J2EE container, it is recommended to use a JNDI DataSource provided by the container. Such a DataSource ...
• RowMapperResultReader: Adapter implementation of the ResultReader interface that delegates to a RowMapper which is supposed to create an object for each row. Each object is added to the results list of this ResultReader. Useful for the typical case of one object per row in the database table. The number of entries in the results list will match the number of rows. Note that a RowMapper object is typically stateless and thus reusable; just the RowMapperResultReader adapter is stateful. A usage example with JdbcTemplate: JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource); // reusable object RowMapper rowMapper = ...
• SingleConnectionDataSource: Implementation of SmartDataSource that wraps a single Connection which is not closed after use. Obviously, this is not multi-threading capable. Note that at shutdown, someone should close the underlying connection via the close() method. Client code will never call close on the Connection handle if it is SmartDataSource-aware (e.g. uses DataSourceUtils.closeConnectionIfNecessary ). If client code will call close() in the assumption of a pooled Connection, like when using persistence tools, set "suppressClose" to "true". This will return a close-suppressing proxy instead of the physical Connection. ...
• RowCallbackHandler: Callback interface used by JdbcTemplate's query methods. Implementations of this interface perform the actual work of extracting results, but don't need to worry about exception handling. SQLExceptions will be caught and handled correctly by the JdbcTemplate class. In contrast to a ResultSetExtractor, a RowCallbackHandler object is typically stateful: It keeps the result state within the object, to be available for later inspection. See RowCountCallbackHandler's javadoc for a usage example with JdbcTemplate. The ResultReader subinterface allows to make a results list available in a uniform manner. ...
• MySQLMaxValueIncrementer: Class to increment maximum value of a given MySQL table with the equivalent of an auto-increment column. Note: If you use this class, your MySQL key column should NOT be auto-increment, as the sequence table does the job. The sequence is kept in a table; there should be one sequence table per table that needs an auto-generated key. The table type of the sequence table should be MyISAM so the sequences are allocated without regard to any transactions that might be in progress. Example: create table tab (id int unsigned not null primary key, text varchar(100)); create table tab_sequence (value int ...
• AbstractLobCreatingPreparedStatementCallback: Abstract PreparedStatementCallback implementation that manages a LobCreator. Typically used as inner class, with access to surrounding method arguments. Delegates to the setValues template method for setting values on the PreparedStatement, using a given LobCreator for BLOB/CLOB arguments. A usage example with JdbcTemplate: JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource); // reusable object LobHandler lobHandler = new DefaultLobHandler(); // reusable object jdbcTemplate.execute( "INSERT INTO imagedb (image_name, content, description) VALUES (?, ?, ?)", new AbstractLobCreatingPreparedStatementCallback(lobHandler) ...
• RdbmsOperation: An "RDBMS operation" is a multithreaded, reusable object representing a query, update or stored procedure. An RDBMS operation is not a command, as a command isn't reusable. However, execute methods may take commands as arguments. Subclasses should be Java beans, allowing easy configuration. Root of the JDBC object hierarchy, as described in Chapter 9 of Expert One-On-One J2EE Design and Development by Rod Johnson (Wrox, 2002). This class and subclasses throw runtime exceptions, defined in the org.springframework.dao package (and as thrown by the org.springframework.jdbc.core package, which the ...
• SqlFunction: SQL "function" wrapper for a query that returns a single row of results. The default behavior is to return an int, but that can be overridden by using the methods with an extra return type parameter. Intended to use to call SQL functions that return a single result using a query like "select user()" or "select sysdate from dual". It is not intended for calling more complex stored functions or for using a CallableStatement to invoke a stored procedure or stored function. Use StoredProcedure or SqlCall for this type of processing. This is a concrete class, which there is normally no need to subclass. ...
• MappingSqlQueryWithParameters: Reusable RDBMS query in which concrete subclasses must implement the abstract mapRow(ResultSet, int) method to map each row of the JDBC ResultSet into an object. Such manual mapping is usually preferable to "automatic" mapping using reflection, which can become complex in non-trivial cases. For example, the present class allows different objects to be used for different rows (for example, if a subclass is indicated). It allows computed fields to be set. And there's no need for ResultSet columns to have the same names as bean properties. The Pareto Principle in action: going the extra mile to automate ...
• HsqlMaxValueIncrementer: Class to increment maximum value of a given HSQL table with the equivalent of an auto-increment column. Note: If you use this class, your HSQL key column should NOT be auto-increment, as the sequence table does the job. The sequence is kept in a table. There should be one sequence table per table that needs an auto-generated key. Example: create table tab (id int not null primary key, text varchar(100)); create table tab_sequence (value identity); insert into tab_sequence values(0); If cacheSize is set, the intermediate values are served without querying the database. If the server or your application ...
• SqlQuery: Reusable object to represent a SQL query. Like all RdbsOperation objects, SqlQuery objects are threadsafe after their initialization is complete. That is, after they are constructed and configured via their setter methods, they can be used safely from multiple threads. Subclasses must implement the newResultReader method to provide an object that can save the results of iterating over the ResultSet. This class provides a number of public execute methods that are analogous to the different convenient JDO query execute methods. Subclasses can either rely on one of these inherited methods, or can ...
• NativeJdbcExtractorAdapter: Abstract adapter class for the NativeJdbcExtractor interface, for simplified implementation of basic extractors. Returns the passed-in JDBC objects on all methods. getNativeConnection checks for a ConnectionProxy chain, for example from a TransactionAwareDataSourceProxy, before delegating to doGetNativeConnection for actual unwrapping. You can override either of the two for a specific connection pool, but the latter is recommended to participate in ConnectionProxy unwrapping. The getNativeConnectionFromStatement method is implemented to simply delegate to getNativeConnection with the Statement's ...
• RowMapper: An interface used by JdbcTemplate for mapping returned result sets. Implementations of this interface perform the actual work of mapping rows, but don't need to worry about exception handling. SQLExceptions will be caught and handled correctly by the JdbcTemplate class. Typically used either for JdbcTemplate's query methods (with RowMapperResultReader adapters) or for out parameters of stored procedures. RowMapper objects are typically stateless and thus reusable; they are ideal choices for implementing row-mapping logic in a single place. Alternatively, consider subclassing MappingSqlQuery from ...
• CommonsDbcpNativeJdbcExtractor: Implementation of the NativeJdbcExtractor interface for the Jakarta Commons DBCP connection pool. Returns the underlying native Connection, Statement, ResultSet etc to application code instead of DBCP's wrapper implementations. The returned JDBC classes can then safely be cast, e.g. to OracleResultSet. This NativeJdbcExtractor can be set just to allow working with a Commons DBCP DataSource: If a given object is not a Commons DBCP wrapper, it will be returned as-is. Tested against Commons DBCP 1.1 and 1.2, but should also work with 1.0. Before Commons DBCP 1.1, DelegatingCallableStatement and DelegatingResultSet ...
• PreparedStatementCallback: Generic callback interface for code that operates on a PreparedStatement. Allows to execute any number of operations on a single PreparedStatement, for example a single executeUpdate call or repeated executeUpdate calls with varying parameters. Used internally by JdbcTemplate, but also useful for application code. Note that the passed-in PreparedStatement can have been created by the framework or by a custom PreparedStatementCreator. However, the latter is hardly ever necessary, as most custom callback actions will perform updates in which case a standard PreparedStatement is fine. Custom actions ...
• ResultSetExtractor: Callback interface used by JdbcTemplate's query methods. Implementations of this interface perform the actual work of extracting results, but don't need to worry about exception handling. SQLExceptions will be caught and handled correctly by the JdbcTemplate class. This interface is mainly used within the JDBC framework. A RowCallbackHandler is usually a simpler choice for ResultSet processing, in particular a RowMapperResultReader in combination with a RowMapper. Note: In contrast to a RowCallbackHandler, a ResultSetExtractor object is typically stateless and thus reusable, as long as it doesn't ...
| Home | Contact Us | Privacy Policy | Terms of Service |