MySQL proporciona conectividad para aplicaciones clientes desarrolladas en el lenguaje de programación Java via el JDBC driver, que se llama MySQL Connector/J.
MySQL Connector/J es un driver JDBC-3.0 "Tipo 4", lo que significa que es puramente Java, implementa la versión 3.0 de la especificación JDBC, y se comunica directamente con el servidor MySQL usando el protocolo MySQL.
Este documento está pensado para un desarrollador de JDBC principiante. Si tiene experiencia usando JDBC, puede considerar comenzar con la sección "Instalación del Connector/J".
Mientras JDBC es útil por sí mismo, nos gustaría que si no conoce JDBC tras leer las primeras secciones de este manual, evite usar JDBC "desnudo" excepto para los problemas triviales y considere usar uno de los populares marcos persistentes tales como Hibernate, Spring's JDBC templates o Ibatis SQL Maps para hacer la mayoría del trabajo repetitivo y pesado que a veces se requiere con JDBC.
Esta sección no está diseñada para ser un tutorial de JDBC completo. Si necesita más información acerca de usar JDBC puede estar interesado en los siguentes tutoriales en línea que son más profundos que la información presentada aquí:
-
JDBC Basics - Tutorial de Sun que cubre tópicos para principiantes en JDBC
-
JDBC Short Course - Tutorial de Sun y JGuru más profundo
Esta sección proporciona algún conocimiento general de JDBC.
Cuando usa JDBC fuera de un servidor de aplicación, la clase DriverManager administra el establecimiento de las conexiones.
El DriverManager necesita que le digan qué drivers JDBC debe usar para hacer la conexión. La forma más fácil de hacerlo es usar Class.forName() en la clase que implemente la interfície java.sql.Driver . Con MySQL Connector/J, el nombre de esta clase es com.mysql.jdbc.Driver. Con este método, puede usar un fichero de configuración externo para proporcionar la clase del driver y los parámetros para usar al conectar a la base de datos.
La siguiente sección de código Java muestra cómo puede registrar MySQL Connector/J desde el método main() de su aplicación:
import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; // Notice, do not import com.mysql.jdbc.* // or you will have problems! public class LoadDriver { public static void main(String[] args) { try { // The newInstance() call is a work around for some // broken Java implementations Class.forName("com.mysql.jdbc.Driver").newInstance(); } catch (Exception ex) { // handle the error } }
Una vez que el driver se ha registrado con el DriverManager, puede obtener una instancia de Connection que está conectada a una base de datos particular llamando a DriverManager.getConnection():
Ejemplo 25.1. Obtener una conexión de DriverManager
Este ejemplo muestra cómo puede obtener una instancia de Connection del DriverManager. El método getConnection tiene pocas formas diferentes. Debe consultar la documentación de la API que ser proporciona con su JDK para información más específica sobre cómo usarlo.
import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; ... try { Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?user=monty&password=greatsqldb"); // Do something with the Connection .... } catch (SQLException ex) { // handle any errors System.out.println("SQLException: " + ex.getMessage()); System.out.println("SQLState: " + ex.getSQLState()); System.out.println("VendorError: " + ex.getErrorCode()); }
Una vez que se establece una conexión, puede usarse para crear Statements y PreparedStatements, así como obtener metadatos sobre la base de datos. Esto se explica en las siguientes secciones.
Statements le permiten ejecutar consultas básicas SQL y recibir los resultados mediante la clase ResultSet que se describe posteriormente.
Para crear una instancia de Statement, debe llamar al método createStatement() en el objeto Connection que ha obtenido via uno de los métodos DriverManager.getConnection() o DataSource.getConnection() descritos anteriormente.
Una vez que tiene una instancia de Statement, puede ejecutar una consulta SELECT llamando al método executeQuery(String) con el SQL que desea usar.
Para acutalizar datos en la base de datos, use el método executeUpdate(String SQL). Este método retorna el número de registros afectados por el comando de actualización.
Si no sabe de antemano si el comando SQL será un SELECT o un UPDATE/INSERT, puede usar el método execute(String SQL). Este método retornará cierto si el comando SQL era un SELECT, o falso si era un comando UPDATE/INSERT/DELETE. Si la consulta era un SELECT, puede recibir los resultados llamando al método getResultSet(). Si la consulta era un UPDATE/INSERT/DELETE, puede recibir el número de registros afectados llamando a getUpdateCount() en la instancia de Statement.
Ejemplo 25.2. Usando java.sql.Statement para ejecutar una consulta SELECT
// assume conn is an already created JDBC connection Statement stmt = null; ResultSet rs = null; try { stmt = conn.createStatement(); rs = stmt.executeQuery("SELECT foo FROM bar"); // or alternatively, if you don't know ahead of time that // the query will be a SELECT... if (stmt.execute("SELECT foo FROM bar")) { rs = stmt.getResultSet(); } // Now do something with the ResultSet .... } finally { // it is a good idea to release // resources in a finally{} block // in reverse-order of their creation // if they are no-longer needed if (rs != null) { try { rs.close(); } catch (SQLException sqlEx) { // ignore } rs = null; } if (stmt != null) { try { stmt.close(); } catch (SQLException sqlEx) { // ignore } stmt = null; } }
A partir de MySQL 5.0 cuando se usa con Connector/J 3.1.1 o
posterior, la interfície
java.sql.CallableStatement
está completamente implementada con la excepción del método
getParameterMetaData()
.
La sintaxis de los procedimientos almacenados de MySQL se docuemta en la sección "Procedimientos almacenados y funciones" del Manual de Referencia de MySQL.
Connector/J expone la funcionalidad de procedimientos
almacenados a través de la interfície de JDBC
CallableStatement
.
El siguiente ejemplo muestra un procedimiento almacenado que
retorna el valor de
inOutParam
incrementado en 1, y la cadena de carácteres pasada via
inputParam
como
ResultSet
:
Ejemplo 25.3. Ejemplo de procedimiento almacenado
CREATE PROCEDURE demoSp(IN inputParam VARCHAR(255), INOUT inOutParam INT) BEGIN DECLARE z INT; SET z = inOutParam + 1; SET inOutParam = z; SELECT inputParam; SELECT CONCAT('zyxw', inputParam); END
Para usar el procedimiento demoSp
con
Connector/J, siga estos pasos:
-
Prepare el comando llamable usando
Connection.prepareCall()
.Tenga en cuenta que tiene que usar la sintaxis de escape JDBC, y que los paréntesis rodeando los parámetros no son opcionales:
Ejemplo 25.4. Usando Connection.prepareCall()
import java.sql.CallableStatement; ... // // Prepare a call to the stored procedure 'demoSp' // with two parameters // // Notice the use of JDBC-escape syntax ({call ...}) // CallableStatement cStmt = conn.prepareCall("{call demoSp(?, ?)}"); cStmt.setString(1, "abcdefg");
Nota
Connection.prepareCall()
es un método costoso, debido a la petición de metadatos que hace el driver para suportar los parámetros de salida. Por razones de rendimiento, intente minimizar llamadas innecesarias aConnection.prepareCall()
reusando instancias deCallableStatement
en su código. -
Registre los parámetros de salida (si existen)
Para recibir los valores de los parámetros de salida (parámetros especificados como
OUT
oINOUT
cuando crea el procedimiento almacenado), JDBC requiere que estén especificados antese de la ejecución del comando usando los varios métodosregisterOutputParameter()
en la interfícieCallableStatement
:Ejemplo 25.5. Registrando parámetros de salida
import java.sql.Types; ... // // Connector/J supports both named and indexed // output parameters. You can register output // parameters using either method, as well // as retrieve output parameters using either // method, regardless of what method was // used to register them. // // The following examples show how to use // the various methods of registering // output parameters (you should of course // use only one registration per parameter). // // // Registers the second parameter as output // cStmt.registerOutParameter(2); // // Registers the second parameter as output, and // uses the type 'INTEGER' for values returned from // getObject() // cStmt.registerOutParameter(2, Types.INTEGER); // // Registers the named parameter 'inOutParam' // cStmt.registerOutParameter("inOutParam"); // // Registers the named parameter 'inOutParam', and // uses the type 'INTEGER' for values returned from // getObject() // cStmt.registerOutParameter("inOutParam", Types.INTEGER); ...
-
Especifique los parámetros de entrada (si existen)
Los parámtros de entrada y de entrada/salida se especifican como en los objetos
PreparedStatement
. Sin embargo,CallableStatement
también soporta especificar los parámetros por nombre:Ejemplo 25.6. Especificando los parámetros de entrada de CallableStatement
... // // Set a parameter by index // cStmt.setString(1, "abcdefg"); // // Alternatively, set a parameter using // the parameter name // cStmt.setString("inputParameter", "abcdefg"); // // Set the 'in/out' parameter using an index // cStmt.setInt(2, 1); // // Alternatively, set the 'in/out' parameter // by name // cStmt.setInt("inOutParam", 1); ...
-
Ejecute
CallableStatement
, y reciba cualquier conjunto de resultados o parámetros de salida.Mientras
CallableStatement
soporta llamar a cualquiera de los métodos de ejecución deStatement
(executeUpdate()
,executeQuery()
oexecute()
), el método más flexible esexecute()
, ya que no necesita saber de antemano si el procedimiento almacenado retorna un conjunto de resultados:Ejemplo 25.7. Recibiendo resultados y parámetros de salida
... boolean hadResults = cStmt.execute(); // // Process all returned result sets // while (hadResults) { ResultSet rs = cStmt.getResultSet(); // process result set ... hadResults = cStmt.getMoreResults(); } // // Retrieve output parameters // // Connector/J supports both index-based and // name-based retrieval // int outputValue = cStmt.getInt(1); // index-based outputValue = cStmt.getInt("inOutParam"); // name-based ...
Antes de la versión 3.0 de la API JDBC , no hay una forma estándar de recibir valores clave de bases de datos que soporten 'auto incremento' o columnas identidad. Con drivers JDBC antiguos para MySQL, siempre puede usar un método específico de MySQL en la interfície Statement, o ejecutar la consulta 'SELECT LAST_INSERT_ID()' tras ejecutar un 'INSERT' a una table que tenga una clave AUTO_INCREMENT. Usando el método específico de MySQL no es portable, y ejecutar el 'SELECT' para obtener el valor de la clave AUTO_INCREMENT require otra consulta a la base de datos, lo que no es lo más eficiente. Las siguientes muestras de código demuestran tres formas distintas de recibir valores AUTO_INCREMENT. Primero, demostramos el uso del nuevo método de JDBC-3.0 'getGeneratedKeys()' que es el método preferido para usar si necesita recibir claves AUTO_INCREMENT y tener acceso a JDBC-3.0. El segundo ejemplo muestra cómo puede recibir el mismo valor usando una consulta estándar 'SELECT LAST_INSERT_ID()'. El ejemplo final muestra como conjuntos de resultados actualizables pueden tener el valor AUTO_INCREMENT usando el método 'insertRow()'.
Ejemplo 25.8. Recibiendo valores de columna AUTO_INCREMENT usando Statement.getGeneratedKeys()
Statement stmt = null; ResultSet rs = null; try { // // Create a Statement instance that we can use for // 'normal' result sets assuming you have a // Connection 'conn' to a MySQL database already // available stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_UPDATABLE); // // Issue the DDL queries for the table for this example // stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial"); stmt.executeUpdate( "CREATE TABLE autoIncTutorial (" + "priKey INT NOT NULL AUTO_INCREMENT, " + "dataField VARCHAR(64), PRIMARY KEY (priKey))"); // // Insert one row that will generate an AUTO INCREMENT // key in the 'priKey' field // stmt.executeUpdate( "INSERT INTO autoIncTutorial (dataField) " + "values ('Can I Get the Auto Increment Field?')", Statement.RETURN_GENERATED_KEYS); // // Example of using Statement.getGeneratedKeys() // to retrieve the value of an auto-increment // value // int autoIncKeyFromApi = -1; rs = stmt.getGeneratedKeys(); if (rs.next()) { autoIncKeyFromApi = rs.getInt(1); } else { // throw an exception from here } rs.close(); rs = null; System.out.println("Key returned from getGeneratedKeys():" + autoIncKeyFromApi); } finally { if (rs != null) { try { rs.close(); } catch (SQLException ex) { // ignore } } if (stmt != null) { try { stmt.close(); } catch (SQLException ex) { // ignore } } }
Ejemplo 25.9. Recibiendo valores de columna AUTO_INCREMENT usando 'SELECT LAST_INSERT_ID()'
Statement stmt = null; ResultSet rs = null; try { // // Create a Statement instance that we can use for // 'normal' result sets. stmt = conn.createStatement(); // // Issue the DDL queries for the table for this example // stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial"); stmt.executeUpdate( "CREATE TABLE autoIncTutorial (" + "priKey INT NOT NULL AUTO_INCREMENT, " + "dataField VARCHAR(64), PRIMARY KEY (priKey))"); // // Insert one row that will generate an AUTO INCREMENT // key in the 'priKey' field // stmt.executeUpdate( "INSERT INTO autoIncTutorial (dataField) " + "values ('Can I Get the Auto Increment Field?')"); // // Use the MySQL LAST_INSERT_ID() // function to do the same thing as getGeneratedKeys() // int autoIncKeyFromFunc = -1; rs = stmt.executeQuery("SELECT LAST_INSERT_ID()"); if (rs.next()) { autoIncKeyFromFunc = rs.getInt(1); } else { // throw an exception from here } rs.close(); System.out.println("Key returned from " + "'SELECT LAST_INSERT_ID()': " + autoIncKeyFromFunc); } finally { if (rs != null) { try { rs.close(); } catch (SQLException ex) { // ignore } } if (stmt != null) { try { stmt.close(); } catch (SQLException ex) { // ignore } } }
Ejemplo 25.10. Recibiendo valores de columna AUTO_INCREMENT en Updatable ResultSets
Statement stmt = null; ResultSet rs = null; try { // // Create a Statement instance that we can use for // 'normal' result sets as well as an 'updatable' // one, assuming you have a Connection 'conn' to // a MySQL database already available // stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_UPDATABLE); // // Issue the DDL queries for the table for this example // stmt.executeUpdate("DROP TABLE IF EXISTS autoIncTutorial"); stmt.executeUpdate( "CREATE TABLE autoIncTutorial (" + "priKey INT NOT NULL AUTO_INCREMENT, " + "dataField VARCHAR(64), PRIMARY KEY (priKey))"); // // Example of retrieving an AUTO INCREMENT key // from an updatable result set // rs = stmt.executeQuery("SELECT priKey, dataField " + "FROM autoIncTutorial"); rs.moveToInsertRow(); rs.updateString("dataField", "AUTO INCREMENT here?"); rs.insertRow(); // // the driver adds rows at the end // rs.last(); // // We should now be on the row we just inserted // int autoIncKeyFromRS = rs.getInt("priKey"); rs.close(); rs = null; System.out.println("Key returned for inserted row: " + autoIncKeyFromRS); } finally { if (rs != null) { try { rs.close(); } catch (SQLException ex) { // ignore } } if (stmt != null) { try { stmt.close(); } catch (SQLException ex) { // ignore } } }
Cuando ejecuta el código de ejemplo anterior, debe obtener la siguiente salida: Clave retornada de getGeneratedKeys(): 1 Clave retornada de 'SELECT LAST_INSERT_ID()': 1 Clave retornada de registros insertados: 2 Debe tener en cuenta que, a veces, puede ser lioso usar la consulta 'SELECT LAST_INSERT_ID()' , ya que el valor de la función está limitado a una conexión. Así que, si otra consulta ocurre en la misma conexión, el valor será sobreescrito. Por otra parte, el método 'getGeneratedKeys()' está limitado a una instancia de Statement , así que puede usarse incluso si ocurren otras consultas en la misma conexión, pero no en la misma instancia de Statement .
Use las siguientes instrucciones para instalar el Connector/J
MySQL Connector/J soporta Java-2 JVMs, incluyendo JDK-1.2.x, JDK-1.3.x, JDK-1.4.x y JDK-1.5.x, y requiere JDK-1.4.x o posterior para compilar (pero no para ejecutarse). MySQL Connector/J no soporta JDK-1.1.x o JDK-1.0.x
Debido a la implementación de java.sql.Savepoint, Connector/J 3.1.0 y posterior no se ejecutarán en JDKs posterior a 1.4 a no ser que el verificador de clases esté desactivado (-Xverify:none), ya que el verificador de clases intentará cargar la definición de la clase para java.sql.Savepoint incluso si no accede a él el driver a no ser que use la funcionalidad savepoint.
La funcionalidad de cacheo proporcionada por Connector/J 3.1.0
o posterior tampoco está disponible para JVMs posterior a
1.4.x, ya que se basa en
java.util.LinkedHashMap
que fue la primera disponible en JDK-1.4.0.
MySQL Connector/J soporta todas las versiones conocidas de MySQL server. Algunas características (claves foranas, conjuntos de resultados actualizables) requieren versiones más recientes de MySQSL para operar.
Al conectar a MySQL server versión 4.1 o posterior, es mejor usar MySQL Connector/J version 3.1, ya que tiene pleno soporte para funcionalidades en las versiones más nuevas del servidor incluyendo carácteres Unicode, vistas, procedimientos almacenados y comandos preparados en el servidor.
Mientras que Connector/J versión 3.0 conecta con MySQL server, versión 4.1 o posterior, e implementa carácteres Unicode y el nuevo mecanismo de autorización, Connector/J 3.0 no se actualizará para soportar nuevas funcionalidades en versiones actuales y futuras del servidor.
MySQL Connector/J se distribuye como archivo .zip o .tar.gz
que contiene las fuentes, los ficheros de clase y ficheros de
clase "binarios" .jar llamados
"mysql-connector-java-[version]-bin.jar
",
y a partir del Connector/J 3.1.8 una versión "debug" del
driver en un fichero llamado
"mysql-connector-java-[version]-bin-g.jar
".
A partir de Connector/J 3.1.9, no proporcionamos los ficheros .class "sin empaquetar", sólo están disponibles en los ficheros JAR que se proporcionan con el driver.
No debe usar la versión "debug" del driver a no ser que se le
diga de hacerlo al reportar un problema o bug a MySQL AB, ya
que no está diseñado para ejecutarse en entornos de
producción, y tendrá un impacto adverso de rendimiento al
usarse. El binario debug depende de la biblioteca Aspect/J,
que se encuentra en el fichero
src/lib/aspectjrt.jar
que se proporciona
con la distribución Connector/J.
Necesitará usar la gui apropiada o utilidad de línea de comandos para descomprimir la distribución (por ejemplo, WinZip para el archivo .zip, y "tar" para el archivo .tar.gz ). Como hay nombres de ficheros potencialmente largos en la distribución, usamos el formato de archivo GNU tar. Necesitará usar GNU tar (o una aplicación que entienda el formato de archivo GNU tar) para desempaquetar la variante de la distribución .tar.gz .
Una vez que ha extraído el archivo de distribución, puede instalar el driver poniendo mysql-connector-java-[version]-bin.jar en su classpath, añadiendo la ruta COMPLETA en su variable de entorno CLASSPATH o especificándolo directamente con la opción de línea de comandos -cp al arrancar la JVM
Si va a usar el driver con JDBC DriverManager, debe usar "com.mysql.jdbc.Driver" como la clase que implementa java.sql.Driver.
Ejemplo 25.11. Inicialización de CLASSPATH en UNIX
El siguiente comando funciona para 'csh' en UNIX:
$ setenv CLASSPATH /path/to/mysql-connector-java-[version]-bin.jar:$CLASSPATH
El comando anterior puede añadirse al fichero de arranque apropiado para el shell de inicio para hacer que MySQL Connector/J esté disponible para todas las aplicaciones Java .
Si quiere usar MySQL Connector/J con un servidor de aplicaciones como Tomcat o JBoss, tenrá que consultar la documentación del vendedor para más información sobre cómo configurar bibliotecas de terceras partes, ya que la mayoría de servidores de aplicaciones ignoran la variable de entorno CLASSPATH. Este documento contiene ejemplos de configuración para algunos servidores de aplicaciones J2EE en la sección "Usando Connector/J con J2EE y otros Java Frameworks", sin embargo la fuente autorizada para información de configuración de pools de conexiones JDBC para su servidor de aplicaciones particular es la documentación para dicho servidor de aplicaciones.
Si está desarrollando servletes y/o JSPs, y su servidor de aplicaciones es J2EE-compliant, puede poner el fichero .jar del driver en el subdirectorio WEB-INF/lib de su aplicación, ya que es la localización estándar para bibliotecas class de terceras clases en aplicaciones web J2EE.
También puede usar las clases MysqlDataSource o MysqlConnectionPoolDataSource en el paquete opcional com.mysql.jdbc.jdbc2.optional , si su servidor de aplicaciones J2EE los soporta o requiere. Las distintas clases MysqlDataSource soportan los siguientes parámetros (a través del método estándar "set"):
-
usuario
-
contraseña
-
nombreDelServidor (consulte las secciones anteriores sobre equipos a prueba de fallos)
-
nombreBaseDeDatos
-
puerto
MySQL AB intenta mantener el proceso de actualización tan fácil como sea posible, sin embargo como pasa con cualquier software, a veces los cambios necesitan hacerse en versiones nuevas para soportar nuevas funcionalidades, mejorar funcionalidades existentes, o cumplir nuevos estándars.
Esta sección tiene información sobre qué tener en cuenta para actualizar de versiones antinguas de Connector/J a otras (o a una nueva versión de MySQL server, con respecto a funcionalidad de JDBC ).
Connector/J 3.1 está diseñado para tener compatibilidad con versiones anteriores a Connector/J 3.0 tanto como sea posible. Los cambios mayores se aislan a nuevas funcionalidades mostradas en MySQL-4.1 y posteriores, que incluyen conjunto de carácteres Unicode, comandos preparados en el servidor, códigos SQLState retornados en mensajes de error por el servidor y varias mejoras de rendimiento que pueden estar activas o desactivadas via propiedades de configuración.
-
Códigos de carácteres Unicode - Consulte la siguientes seción, así como la sección "Conjuntos de carácteres" en el manual del servidor para información de esta nueva funcionalidad de MySQL. Si tiene algo mal configurado, normalmente mostrará un error con un mensaje similar a "Mezcla ilegal de colaciones".
-
Comandos preparados en el servidor - Connector/J 3.1 automáticamente detecta y usa comandos preparados en el servidor cuando están disponibles (versión de MySQL 4.1 y posterior).
A partir de la versión 3.1.7, el driver escanea el SQL que está preparando via todas las variantes de
Connection.prepareStatement()
para determinar si es un tipo de comandos soportado para preparar en el servidor, y si no es soportado por el servidor, lo prepara como un comando preparado emulado en el cliente. Puede desactivar esta característica pasando 'emulateUnsupportedPstmts=false' en JDBC URL.Si su aplicación encuentra problemas con comandos preparados en el servidor, puede volver al código de comando preparado en el cliente que se usaba en MySQL server anterior a 4.1.0 con la siguiente propiedad de conexión:
useServerPrepStmts=false
-
Fechas con todos los componentes a cero ('0000-00-00 ...') - Estos valores no pueden representarse correctamente en Java. Connector/J 3.0.x siempre los convierte a NULL cuando empieza a leer de un ResultSet.
Connector/J 3.1 lanza una excepción por defecto cuando estos valores se encuentran ya que es el comportamiento más correcto según los estándars JDBC y SQL . Este comportamiento puede modificarse usando la propiedad de configuración ' zeroDateTimeBehavior '. Los valores disponibles son: 'exception' (por defecto), que lanza una excepción SQLException con SQLState de 'S1009', 'convertToNull', que retorna NULL en lugar de la fecha, y 'round', que redondea la fecha al valor más cercano que es '0001-01-01'.
Desde Connector/J 3.1.7, ResultSet.getString() puede desligarse de este comportamiento via ' noDatetimeStringSync=true ' (el valor por defecto es 'false') de forma que pueda recibir el valor de ceros inalterado como cadena de carácteres. Debe tenerse en cuenta que esto deshabilita usar cualquier conversión de zona horaria, por lo tanto el driver no permitirá activar noDatetimeStringSync y useTimezone al mismo tiempo.
-
Nuevos códigos de SQLState - Connector/J 3.1 usa los códigos SQLState SQL:1999 retornados por MySQL server (si está soportado), que son distintos de los códigos de estado "heredados" X/Open que usa Connector/J 3.0. Si está conectado a un servidor MySQL anterior a MySQL-4.1.0 (la versión más vieja que retorna SQLStates como parte del código de error), el driver usará un mapeo por defecto. Puede usar el viejo mapeo usando las siguientes propiedades de configuración:
useSqlStateCodes=false
-
LLamar ResultSet.getString() en una columna BLOB retornará la dirección del array byte[] que lo representa en lugar de una representación de cadenas de carateres del BLOB. BLOBs no tienen conjunto de carácteres, así que no pueden convertirse a java.lang.Strings sin pérdida de datos o corrupción.
Para almacenar cadenas de carácteres en MySQL con comportamiento LOB , use uno de los tipos TEXT , donde el driver lo tratará como java.sql.Clob.
-
A partir de Connector/J 3.1.8 una versión "debug" del driver llamada "
mysql-connector-java-[version]-bin-g.jar
" se proporciona además del fichero "binario" jar que se llama "mysql-connector-java-[version]-bin.jar
".A partir de Connector/J 3.1.9, no proporcionamos los ficheros .class "sin empaquetar", sólo están disponibles en los ficheros JAR que se proporcionan con el driver.
No debe usar la versión "debug" del driver a no ser que se le diga que lo haga al reportar un problema o bug a MySQL AB, ya que no está diseñado para ejecutarse en entornos de producción, y tendrá un impacto negativo en el rendimiento al usarse. El binario de debug depende de la biblioteca Aspect/J, localizada en el fichero
src/lib/aspectjrt.jar
que viene en la distribución Connector/J.
-
Usando la codificación de carácteres UTF-8 - Antes de MySQL server versión 4.1, la codificación de carácteres UTF-8 no era soportada por el servidor, sin embargo, el driver JDBC podía usarla, permitiendo almacenamiento de varios conjuntos de carácteres en tablas latin1 del servidor.
A partir de MySQL-4.1, esta funcionalidad está obsoleta. Si tiene aplicaciones que se basan en esta funcionalidad, y no puede actualizarlas a que usen el soporte oficial de carácteres Unicode en MySQL versión 4.1 o posterior, debe añadir la siguiente propiedad a su URL de la conexión:
useOldUTF8Behavior=true
-
Comandos preparados en el servidor - Connector/J 3.1 detecta automáticamente y usa comandos preparados en el servidor cuando está disponible (MySQL versión 4.1.0 y posterior). Si su aplicación tiene problemas con los comandos preparados en el servidor, puede volver a los comandos preparados emulados en el cliente que se usa en servidores MySQL anteriores a 4.1.0 con la siguiente propiedad de conexión:
useServerPrepStmts=false
El nombre de la clase que implementa el java.sql.Driver en MySQL Connector/J es 'com.mysql.jdbc.Driver'. El nombre de clase 'org.gjt.mm.mysql.Driver' también es usable para compatibilidad con MM.MySQL. Debe usar este nombre de clase al registrar el driver, o al configurar el software para usar MySQL Connector/J.
El formato JDBC URL para MySQL Connector/J es como sigue, con los elementos opcionales entre corchetes ([, ]) :
jdbc:mysql://[host][,failoverhost...][:port]/[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
Si el nombre de equipo no se especifica, por defecto es '127.0.0.1'. Si no se especifica el puerto, por defecto es '3306', el puerto por defecto para servidores MySQL.
jdbc:mysql://[host:port],[host:port].../[database][?propertyName1][=propertyValue1][&propertyName2][=propertyValue2]...
Si no se especifica la base de datos, la conexión se hará sin base de datos específica. En este caso, necesitará llamar al método 'setCatalog()' en la instancia de Connection o especificar completamente el nombre de las tablas con el nombre de la base de datos (p.e. 'SELECT dbname.tablename.colname FROM dbname.tablename...') en su SQL. El no especificar la base de datos en la conexión es sólo útil al construir herramientas con varias bases de datos, como administradores GUI de bases de datos.
MySQL Connector/J tiene controlo de errores. Esto permite al driver soportar el fallo de cualquier número de equipos "esclavos" y todavía hacer consultas de sólo lectura. El control de errores sólo ocurre cuando la conexión está en estado autoCommit(true), ya que el control de errores no puede realizarse cuando hay una transacción en progreso. La mayoría de servidores de aplicación y pools de conexiones tienen autoCommit activado al final de cada transacción/conexión.
La funcionalidad de control de errores tiene el siguiente comportamiento:
Si la propiedad URL "autoReconnect" es falsa: EL control de errores sólo ocurre en la inicialización de la conexión, y el fallo ocurre cuando el driver determina que el primer equipo vuelve a estar disponible.
Si la propiedad URL "autoReconnect" es cierta: El control de errores ocurre cuando el driver determina que la conexión ha fallado (antes de cada consulta), y vuelve al primer equipo cuando determina que el equipo está disponible de nuevo ( después que las consultas queriesBeforeRetryMaster se han realizado).
En cualquier caso, cada vez que esté conectado a un servidor con control de errores, la conexión pasa al estado de sólo lectura, de forma que las consultas nunca se procesarán en el MySQL server).
Las propiedades de configuración definen cómo el Connector/J hace una conexión con el MySQL server. A no ser que se especifique lo contrario, las propiedades pueden asignarse para objetos DataSource o para objetos Connection .
Las propiedades de configuración pueden asignarse de una de las siguientes maneras:
-
Usando los métodos set*() en implementaciones MySQL de java.sql.DataSource (que es el método preferido cuando se usan implementaciones de java.sql.DataSource):
-
com.mysql.jdbc.jdbc2.optional.MysqlDataSource
-
com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource
-
-
Como par clave/valor en la instancia java.util.Properties pasada a DriverManager.getConnection() o Driver.connect()
-
Como parámetro JDBC URL en la URL dada a java.sql.DriverManager.getConnection(), java.sql.Driver.connect() o la implementación MySQL del método javax.sql.DataSource's setURL() .
Nota
Si el mecanismo que usa para configurar una JDBC URL es XML-based, necesitará usar el carácter XML literal & para separar los parámetros de configuración ya que el "ampersand" (&) es un carácter reservado para XML.
Las propiedades se listan en la siguiente tabla:
Tabla 25.1. Propiedades de conexión
Nombre de propiedad | Definición | Requerido? | Valor por defecto | Desde la versión |
---|---|---|---|---|
Conexión/Autenticación | ||||
user | El usuario para conectar como | No | all | |
password | La contraseña usada al conectar | No | all | |
socketFactory | Nombre de la clase que debe usar el driver para crear las conexiones socket con el servidor. Esta clase debe implementar la interfaz 'com.mysql.jdbc.SocketFactory' y tener un constructor público sin argumentos. | No | com.mysql.jdbc.StandardSocketFactory | 3.0.3 |
connectTimeout | Tiempo máximo para conectar al socket (en milisegundos), 0 significa que no hay límite. Sólo funciona en JDK-1.4 o posterior. Por defecto es '0'. | No | 0 | 3.0.1 |
socketTimeout | Tiempo máximo en operaciones de red del socket (0, por defecto significa que no hay tiempo máximo). | No | 0 | 3.0.1 |
useConfigs | Carga la lista de propiedades de configuración separados por comas antes de parsear la URL o aplicar propiedades específicas de usuario. Estas configuraciones se explican en 'Configuraciones' de la documentación. | No | 3.1.5 | |
interactiveClient | Activa el flag CLIENT_INTERACTIVE , que le dice a MySQL que aborte conexiones basadas en INTERACTIVE_TIMEOUT en lugar de WAIT_TIMEOUT | No | false | 3.1.0 |
propertiesTransform | Una implementación de com.mysql.jdbc.ConnectionPropertiesTransform que el driver usará para modificar propiedades URL pasadas al driver antes de intentar una conexión | No | 3.1.4 | |
useCompression | Usa compresión zlib al comunicar con el servidor (true/false)? Por defecto es 'false'. | No | false | 3.0.17 |
Alta disponibilidad y Clustering | ||||
autoReconnect | Debe el driver intentar reestablecer conexiones atascadas y/o muertas? Si está activo el driver lanza una excepción para consultas lanzadas en conexiones atascadas o muertas, que pertenecen a la transacción actual, pero tratarán de reconectar antes de la siguiente consulta ejecutada en la conexión en una nueva transacción. El uso de esta característica no está recomendado, ya que tiene efectos relacionados con el estado de la sesión y la consistencia de datos cuando las aplicaicones no tratan las SQLExceptions apropiadamente, y sólo está diseñado para usarse cuando no es capaz de configurar su aplicación para tratar SQLExceptions resultantes de conexiones atascadas y/o muertas. Alternativamente, investigue las propiedades de la variable de MySQL "wait_timeout" para valores altos en lugar del valor por defecto de 8 horas. | No | false | 1.1 |
autoReconnectForPools | Usa una estrategia de reconexión apropiada para pools de conexiones (por defecto a 'false') | No | false | 3.1.3 |
failOverReadOnly | Cuando falla en modo autoReconnect , debe ponerse la conexión en modo 'sólo lectura'? | No | true | 3.0.12 |
reconnectAtTxEnd | Si autoReconnect es cierto, debe el driver intentar reconexiones tras cada transacción? | No | false | 3.0.10 |
roundRobinLoadBalance | Cuando autoReconnect está activo y failoverReadonly es falso, debemos elegir equipos para conectar en modo round-robin ? | No | false | 3.1.2 |
queriesBeforeRetryMaster | Número de consultas a lanzar antes de volver al maestro cuando falla (cuando se usa control de errores de multi equipos). La condición que se encuentr primero , 'queriesBeforeRetryMaster' o 'secondsBeforeRetryMaster' causará un intento de reconexión al maestro. Por defecto es 50. | No | 50 | 3.0.2 |
secondsBeforeRetryMaster | Cuánto debe esperar el driver, cuando falla, antes de intentar reconectar al servidor maestro? La condición que se encuentre primero, 'queriesBeforeRetryMaster' o 'secondsBeforeRetryMaster' causará un intento de reconexión al maestro. El tiempo es en segundos, y por defecto es 30 | No | 30 | 3.0.2 |
enableDeprecatedAutoreconnect | La funcionalidad de auto-reconectar está obsoleta desde la versión 3.2 y se eliminará en la versión 3.3. Poner esta propiedad a 'true' para desactivar el chequeo para configurar la característica. | No | false | 3.2.1 |
Security | ||||
allowMultiQueries | Permite el uso de ';' para delimitar múltiples consultas durante un comando (true/false, por defecto es 'false' | No | false | 3.1.1 |
useSSL | Usa SSL al comunicar con el servidor (true/false), por defecto es 'false' | No | false | 3.0.2 |
requireSSL | Requiere conexión SSL si useSSL=true? (por defecto es 'false'). | No | false | 3.1.0 |
allowUrlInLocalInfile | Debe permitir el driver URLs en comandos 'LOAD DATA LOCAL INFILE'? | No | false | 3.1.4 |
paranoid | Toma medidas para prevenir la exposición de información sensible en mensajes de error y estructuras de datos transparentes con datos sensibles cuando sea posible? (por defecto es 'false') | No | false | 3.0.1 |
Extensiones de rendimiento | ||||
metadataCacheSize | Número de consultas para cacheResultSetMetadata por si cacheResultSetMetaData es 'true' (por defecto es 50) | No | 50 | 3.1.1 |
prepStmtCacheSize | Si el cacheo de comandos preparados está activado, cuántos comandos preparados deben cachearse? | No | 25 | 3.0.10 |
prepStmtCacheSqlLimit | Si el cacheo de comandos preparados está activado, cuál es el mayor SQL que el driver cacheará? | No | 256 | 3.0.10 |
maintainTimeStats | Debe el driver mantener varios temporizadores internos para permitir cálculos en tiempo inactivo además de mensajes de error más explícitos cuando fallan las conexiones al servidor? Poner esta propiedad a falso elimina al menos dos llamadas a System.getCurrentTimeMillis() por consulta. | No | true | 3.1.9 |
blobSendChunkSize | Tamaño de trozo a usar cuando se envía BLOB/CLOBs via ServerPreparedStatements | No | 1048576 | 3.1.9 |
cacheCallableStmts | Debe el driver cachear la etapa de parseo de CallableStatements | No | false | 3.1.2 |
cachePrepStmts | Debe el driver cachear la etapa de parseo de PreparedStatements de comandos preparados en el cliente, el "chequeo" para ver si están disponibles los comandos preparados en el cliente y en el servidor? | No | false | 3.0.10 |
cacheResultSetMetadata | Debe el driver cachear ResultSetMetaData para Statements y PreparedStatements? (Req. JDK-1.4+, true/false, por defecto 'false') | No | false | 3.1.1 |
cacheServerConfiguration | Debe el driver cachear los resultados de 'SHOW VARIABLES' y 'SHOW COLLATION' para cada URL? | No | false | 3.1.5 |
dontTrackOpenResources | La especificación JDBC requiere que el driver tracee y cierre automáticamente los recursos, sin embargo si su aplicación no hace un buen trabajo de llamar específicamene a close() en comandos o conjuntos de resultados, puede causar falta de memoria. Poner esta propiedad a true relaja esta restricción, y puede ser más eficiente en cuanto a memoria para algunas aplicaciones. | No | false | 3.1.7 |
dynamicCalendars | Debe el driver recibir el calendario por defecto cuando se requiera, o cachearlo para cada conexión/sesión? | No | false | 3.1.5 |
elideSetAutoCommits | Si usa MySQL-4.1 o posterior, debe el driver ejecutar sólo consultas 'set autocommit=n' cuando el estado del servidor no coincida con el estado pedido por Connection.setAutoCommit(boolean)? | No | false | 3.1.3 |
holdResultsOpenOverStatementClose | Debe el driver cerrar los conjuntos de resultados en Statement.close() como se requiere en la especificación de JDBC? | No | false | 3.1.7 |
locatorFetchBufferSize | Si 'emulateLocators' se configura a 'true', qué tamaño de búffer debe usarse al tratar datos BLOB para getBinaryInputStream? | No | 1048576 | 3.2.1 |
useFastIntParsing | Usar rutinas de conversión interna String->Integer para evitar creación excesiva de objetos? | No | true | 3.1.4 |
useLocalSessionState | Debe el driver referirse a valores internos de autocommit e isolación de transacciones que se asignan por Connection.setAutoCommit() y Connection.setTransactionIsolation(), en lugar de consultar la base de datos? | No | false | 3.1.7 |
useNewIO | Debe usar el driver las interfícies java.nio.* para comunicación de red (true/false), por defecto es 'false' | No | false | 3.1.0 |
useReadAheadInput | Usa el último, optimizado y no bloqueante, torrente de entrada usando búffer al leer del servidor? | No | true | 3.1.5 |
Depurar/Creación de perfiles | ||||
logger | El nombre de una clase que implementa 'com.mysql.jdbc.log.Log' que se usa para loguer mensajes .(por defecto es 'com.mysql.jdbc.log.StandardLogger', que loguea en STDERR) | No | com.mysql.jdbc.log.StandardLogger | 3.1.1 |
profileSQL | Tracea consultas y su tiempo de ejecución/lectura de datos al log configurado (true/false) por defecto es 'false' | No | false | 3.1.0 |
reportMetricsIntervalMillis | Si 'gatherPerfMetrics' está activo, con qué frecuencia deben loguearse (en ms)? | No | 30000 | 3.1.2 |
maxQuerySizeToLog | Controla el máximo tamaño/longitud de una consulta que se logueará al crear un perfil o traceo | No | 2048 | 3.1.3 |
packetDebugBufferSize | Número máximo de paquetes a mantener cuando 'enablePacketDebug' es true | No | 20 | 3.1.3 |
slowQueryThresholdMillis | Si 'logSlowQueries' está activo, cuánto puede durar la consulta (en ms) antes de ser logueada como 'lenta'? | No | 2000 | 3.1.2 |
useUsageAdvisor | Debe el driver mostrar advertencias 'de uso' advirtiendo uso apropiado y eficiente de JDBC y MySQL Connector/J en el log (true/false, por defecto es 'false')? | No | false | 3.1.1 |
autoGenerateTestcaseScript | Debe el driver volcar el SQL que está ejecutando, incluyendo comandos preparados en el servidor en STDERR? | No | false | 3.1.9 |
dumpQueriesOnException | Debe el driver volcar los contenidos de la consulta enviada al servidor en el mensaje para SQLExceptions? | No | false | 3.1.3 |
enablePacketDebug | Cuando está activo, se guarda un búffer circular de paquetes con tamaño 'packetDebugBufferSize' , y volcados cuando se lanzan excepciones en áreas claves del código del driver | No | false | 3.1.3 |
explainSlowQueries | Si 'logSlowQueries' está activo, debe el driver ejecutar un 'EXPLAIN' automáticamente al servidor y enviar los resultados al log condigurado en nivel WARN? | No | false | 3.1.2 |
logSlowQueries | Deben las consultas que tarden más de 'slowQueryThresholdMillis' loguearse? | No | false | 3.1.2 |
traceProtocol | Debe el protocolo de red a nivel de trazas loguearse? | No | false | 3.1.2 |
Varios | ||||
useUnicode | Debe el driver usar codificación de carácteres Unicode en el tratamiento de cadenas de carácteres? Debe usarse sólo cuando el driver no puede determinar el mapeo del conjunto de carácteres, o trata de forzar al driver de usar un conjunto de carácteres que MySQL no soporta nativamente (como UTF-8), true/false, por defecto es 'true' | No | false | 1.1g |
characterEncoding | Si 'useUnicode' es cierto, qué codificación de carácteres debe usar el driver cuando trata cadenas de carácteres? (por defecto es 'autodetect') | No | 1.1g | |
characterSetResults | Conjunto de carácteres para decir al servidor cómo retornar los resultados. | No | 3.0.13 | |
connectionCollation | Si está activo, le dice al servido usar la colación via 'set collation_connection' | No | 3.0.13 | |
sessionVariables | Lista separada por comas de pares nombre/valor a enviar como SET SESSION ... al servidor cuando conecta el driver. | No | 3.1.8 | |
allowNanAndInf | Debe el driver permitir valores NaN o +/- INF en PreparedStatement.setDouble()? | No | false | 3.1.5 |
autoDeserialize | Debe el driver detectar automáticamente y de-serializar objetos almacenados en campos BLOB ? | No | false | 3.1.5 |
capitalizeTypeNames | Poner en mayúsculas los nombres de tipos en DatabaseMetaData? (normalmente útil cuando se usan WebObjects, true/false, por defecto es 'false') | No | false | 2.0.7 |
clobberStreamingResults | Esto provoca que un ResultSet 'streaming' se cierre automáticamente, y cualquier dato fuera de lo normal que todavía haga streaming desde el servidor será descartada si otra consulta se ejecuta antes que todos los datos se hayan leído desde el servidor. | No | false | 3.0.9 |
continueBatchOnError | Debe el driver continuar procesando comandos batch si falla un comando. La especificación JDBC permite hacerlo (por defeco 'true'). | No | true | 3.0.3 |
createDatabaseIfNotExist | Crea la base de datos dada en la URL si no existe. Asume que el usuario configurado tiene permisos de creación. | No | false | 3.1.9 |
emptyStringsConvertToZero | Debe el driver permitir conversiones de campos de cadenas de carácteres vacías a '0'? | No | true | 3.1.8 |
emulateLocators | N/A | No | false | 3.1.0 |
emulateUnsupportedPstmts | Debe el driver detectar comandos preparados que no son soportados por el servidor, y replazarlos con la versión emulada en el cliente? | No | true | 3.1.7 |
ignoreNonTxTables | Ignorar advertencias de tablas no-transaccionales para hacer rollback? (por defecto es 'false'). | No | false | 3.0.9 |
jdbcCompliantTruncation | Debe el driver lanzar excepciones java.sql.DataTruncation cuando se truncan los datos como requiere la especificación JDBC cuando se conecta a un servidor que soporte advertencias (MySQL 4.1.0 y posterior)? | No | true | 3.1.2 |
maxRows | Número máximo de registros a retornar (0, por defecto significa retornar todos los registros). | No | -1 | all versions |
noDatetimeStringSync | No asegura que ResultSet.getDatetimeType().toString().equals(ResultSet.getString()) | No | false | 3.1.7 |
nullCatalogMeansCurrent | Cuando DatabaseMetadataMethods pide un parámetro 'catálogo', significa el valor nulo que use el catálogo actual? (esto no es un estándar de JDBC, pero sigue el comportamiento heredado de versiones anteriores del driver) | No | true | 3.1.8 |
nullNamePatternMatchesAll | Debe el método DatabaseMetaData que acepta parámetros *pattern tratar nulo lo mismo que '%' (esto no es un estándar JDBC, sin embargo versiones anteriores del driver aceptaban esta excepción de la especificación) | No | true | 3.1.8 |
pedantic | Sigue la especificación JDBC rigurosamente. | No | false | 3.0.0 |
relaxAutoCommit | Si la versión a la que conecta el driver MySQL no soporta transacciones, permite llamadas a commit(), rollback() y setAutoCommit() (true/false, por defecto es 'false')? | No | false | 2.0.13 |
retainStatementAfterResultSetClose | Debe reterner el driver la referencia Statement en un ResultSet tras la llamada a ResultSet.close(). Esto no sigue el estándar JDBC-compliant desde JDBC-4.0. | No | false | 3.1.11 |
rollbackOnPooledClose | Debe realizar un rollback() el driver cuando las conexiones lógicas en un pool se cierran? | No | true | 3.0.15 |
runningCTS13 | Permite soluciones para bubs en Sun JDBC compliance testsuite version 1.3 | No | false | 3.1.7 |
serverTimezone | No realiza detección/mapeo de zona horaria. Usada cuando la zona horaria del servidor no mapea a la zona horara de Java | No | 3.0.2 | |
strictFloatingPoint | Usado sólo en versiones antiguas del test de cumplimiento | No | false | 3.0.0 |
strictUpdates | Debe el driver hacer chequeo estricto (todas las claves primarias seleccionadas) de conjuntos de resultados actualizables (true, false, por defecto es 'true')? | No | true | 3.0.4 |
tinyInt1isBit | Debe el driver tratar el tipo de datos TINYINT(1) como BIT ( ya que el driver convierte silenciosamente BIT -> TINYINT(1) cuando crea tablas)? | No | true | 3.0.16 |
transformedBitIsBoolean | Si el driver convierte TINYINT(1) a un tipo distinto, debe usar BOOLEAN en lugar de BIT para compatibilidad futura con MySQL-5.0, ya que MySQL-5.0 tiene tipo BIT ? | No | false | 3.1.9 |
ultraDevHack | Crea PreparedStatements para prepareCall() cuando se requiere, ya que UltraDev está roto y realiza un prepareCall() para _todos_ los comandos? (true/false, por defecto es 'false') | No | false | 2.0.3 |
useHostsInPrivileges | Añade '@hostname' a usuarios en DatabaseMetaData.getColumn/TablePrivileges() (true/false), por defecto es 'true'. | No | true | 3.0.2 |
useOldUTF8Behavior | Usa el comportamiento UTF-8 el driver al comunicar con servidores 4.0 y anteriores | No | false | 3.1.6 |
useOnlyServerErrorMessages | No antepone mensaes de error 'estándar' SQLState a mensajes de error retornados por el servidor. | No | true | 3.0.15 |
useServerPrepStmts | Usa comandos preparados en el servidor si el servidor los soporta? (por defecto es 'true'). | No | true | 3.1.0 |
useSqlStateCodes | Usa códigos de error SQL Standard en lugar de códigos de estado X/Open/SQL 'heredados' (true/false), por defecto es 'true' | No | true | 3.1.3 |
useStreamLengthsInPrepStmts | Honara la longitud de parámetros de flujo en llamadas al método PreparedStatement/ResultSet.setXXXStream() (true/false, por defecto es 'true')? | No | true | 3.0.2 |
useTimezone | Convierte tipos fecha/hora entre zonas horarias del cliente y el servidor (true/false, por defecto es 'false')? | No | false | 3.0.2 |
useUnbufferedInput | No usa BufferedInputStream para leer datos del servidor | No | true | 3.0.11 |
yearIsDateType | Debe el driver JDBC tratar el tipo MySQL "YEAR" como java.sql.Date, o como SHORT? | No | true | 3.1.9 |
zeroDateTimeBehavior | Qué debe ocurrir cuando el driver encuentra valores DATETIME que están compuestos enteramente de ceros (usado por MySQL para representar fechas inválidas)? Valores válidos son 'exception', 'round' y 'convertToNull'. | No | exception | 3.1.4 |
Connector/J también soporta acceso a MySQL via named pipes en Windows NT/2000/XP usando 'NamedPipeSocketFactory' como plugin-socket factory via la propiedad 'socketFactory'. Si no usa una 'namedPipePath' apropiadamente, se usa por defecto '\\.\pipe\MySQL'. Si usa NamedPipeSocketFactory, el nombre de equipo y puerto en la url JDB se ignoran.
Añadiendo la siguiente propiedad a la URL activa la NamedPipeSocketFactory:
socketFactory=com.mysql.jdbc.NamedPipeSocketFactory
Named pipes sólo funcionan al conectar a un MySQL server en la misma máquina en la que se usa el driver JDBC. En tests de rendimiento simples, parece que el acceso por named pipe es entre un 30%-50% más rápido que acceso TCP/IP estándar.
Puede crear sus propias factorías socket siguiendo el siguiente
código de ejemplo en
com.mysql.jdbc.NamedPipeSocketFactory
, o
com.mysql.jdbc.StandardSocketFactory
.
MySQL Connector/J pasa todos los tests en la versión pública disponible del suite de test de cumplimiento JDBC de Sun. Sin embargo, en muchas partes la especificación JDBC es vaga sobre cómo deben implementarse ciertas funcionalidades, o la especificación permite libertad en la implementación.
Esta sección da detalles a un nivel interfaz-por-interfaz acerca cómo ciertas decisiones de implementación pueden afectar cómo usar el MySQL Connector/J.
-
Blob
La implementación Blob no permite modificación in-situ (hay 'copias', como se reporta en el método DatabaseMetaData.locatorsUpdateCopies() ). Debido a eso, debe usar el correspondiente PreparedStatement.setBlob() o ResultSet.updateBlob() (en el caso de conjuntos de resultados actualizables) para guardar cambios en la base de datos.
A partir de Connector/J versión 3.1.0, puede emular Blobs con localizadores añadiendo la propiedad 'emulateLocators=true' en la URL de JDBC . Debe usar un alias de columna con el valor de la columna asignado con el nombre real de la columna Blob. El SELECT debe referenciar sólo a una tabla, la tabla debe tener una clave primaria, y el SELECT debe cubrir todas las columnas que forman la clave primaria. El driver retardará cargar los datos Blob hasta que reciba los métodos Blob (getInputStream(), getBytes(), etc) .
-
CallableStatement
Desde Connector/J 3.1.1, los procedimientos almacenados se soportan al conectar a MySQL versión 5.0 o posterior via la interfaz
CallableStatement
. Actualmente no se soporta el métodogetParameterMetaData()
deCallableStatement
. -
Clob
La implementación Clob no permite moficicación in-situ (hay 'copias', como se explica en el método DatabaseMetaData.locatorsUpdateCopies() ). Debido a esto, debe usar el método PreparedStatement.setClob() para salvar los cambios en la base de datos. La API JDBC no tiene un método ResultSet.updateClob().
-
Connection
Diferentemente a otras versiones de MM.MySQL el método 'isClosed()' no hace "ping" al servidor para determinar si está vivo. En concordancia con la especificación JDBC , sólo retorna cierto si se ha llamado a 'closed()' en la conexión. Si necesita determinar si la conexión todavía es válida, debe realizar una consulta simple, como "SELECT 1". El driver lanzará una excepción si la conexión no sigue siendo válida.
-
DatabaseMetaData
Clave sobre la clave forana (getImported/ExportedKeys() y getCrossReference()) sólo está disponible de tablas tipo 'InnoDB'. Sin embargo, el driver usa 'SHOW CREATE TABLE' para recibir esta información, así que cuando otros tipos de tabla soportan claves foráneas, el driver las soporta también transparentemente.
-
Driver
-
PreparedStatement
PreparedStatements se implementan por el driver, ya que MySQL no tiene la característica de comandos preparados. Debido a ello, el driver no implementa getParameterMetaData() o getMetaData() como requiere el driver para tener un parser SQL completo en el cliente.
A partir de la versión 3.1.0 MySQL Connector/J, los comandos preparados en el servidor y los conjuntos de resultados con codificación binaria se usan cuando lo soporta el servidor.
Tenga cuidado al usar comandos preparados en el servidor con parámetros "grandes" que se asignan via setBinaryStream(), setAsciiStream(), setUnicodeStream(), setBlob(), o setClob(). Si quiere re-ejecutar el comando con cualquier parámetro "grande" cambiado a un parámetro no-"grande", es necesario llamar a clearParameters() y asignar todos los parámetros de nuevo. La razón es la siguiente:
-
El driver envía los datos 'grandes' al comando preparado en el servidor por otro lado cuando se asigna un valor al parámetro (antes de la ejecución del parámetro preparado).
-
Una vez hecho esto, el flujo usado para leer los datos en el lado del cliente se cierra (por la especificación de JDBC), y no puede leerse de nuevo.
-
Si un parámetro cambia de un valor "grande" a uno no-"grande", el driver debe resetear el estado del servidor del comando preparado para permitir al parámetro que ha cambiado tomar el valor del valor "grande" anterior. Esto elimina todos los datos 'grandes' que se han enviado al servidor, por lo tanto requiriendo que los datos se vuelvan a enviar, via los métodos setBinaryStream(), setAsciiStream(), setUnicodeStream(), setBlob() o setClob() .
Consecuentemente, si quiere cambiar el "tipo" de un parámetro a uno no-"grande", debe llamar clearParameters() y asignar todos los parámetros del comando preparado de nuevo antes que pueda ser re-ejecutado.
-
-
ResultSet
Por defecto, los ResultSets se reciben completamente y se almacenan en memoria. En la mayoría de casos, esta es la forma más eficiente de operar, y debido al diseño del protocolo de red de MySQL es más fácil de implementar. Si está trabando con ResultSets que tienen un gran número de registros o valores grandes, y no puede reservar espacio en su JVM para la memoria requerida, puede decirle al driver que 'envíe mediante un flujo' los resultados de vuelta registro a registro.
Para permititr esta funcionalidad, necesita crear una instancia de Statement de la siguiente manera:
stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY); stmt.setFetchSize(Integer.MIN_VALUE);
La combinación de un conjunto de resultados de sólo lectura, con un tamaño de Integer.MIN_VALUE sirve como señal al driver para "stream" conjunto de resultados registro a registro. Tras esto cualquier conjunto de resultados creado con el comando se recibe registro a registro.
Hay algunas lagunas con esta aproximación. Tiene que leer todos los registros en el conjunto de resultados (o cerrarlo) antes que pueda realizar ninguna otra consulta con la conexión, o se lanzará una excepción.
El primero de los bloqueos que tratan estos comandos puede liberarse (sean bloqueos de tabla MyISAM o bloqueos a nivel de registro en cualquier otro motor de almacenamiento como InnoDB) cuando se completa el comando.
Si el comando está en una transacción, entonces los bloqueos se liberan cuando se completa (lo que implica que el comando necesita completarse antes). Como con la mayoría de las otras bases de datos, los comandos no se completan hasta que todos los resultados pendientes en el comando se leen o el conjunto de resultados activo para el comando se cierra.
Por lo tanto, si usa resultados "streaming", debe procesarlos tan rápido como sea posible si quiere mantener aceso concurrente a las tablas referenciadas por el comando que produce el conjunto de resultados.
-
ResultSetMetaData
El método "isAutoIncrement()" sólo funciona con MySQL servers 4.0 y posterior.
-
Statement
Al usar versiones del driver JDBC anteriores a 3.2.1, y conectado a versiones del servidor anteriores a 5.0.3, el método "setFetchSize()" no tiene efecto, otro que tratar el streaming del conjunto de resultados como se describe anteriormente.
MySQL no soporta cursores SQL, y el driver JDBC no los emula, así que "setCursorName()" no tiene efecto.
MySQL Connector/J es flexible en el sentido que trata conversiones entre tipos de datos MySQL y tipos de datos Java .
En general, cualquier tipo de datos MySQL puede convertirse a java.lang.String, y cualquier tipo numérico puede convertirse a cualquier tipo de datos numérico de Java, aunque puede haber redondeo, overflow o pérdida de precisión.
A partir de Connector/J 3.1.0, el driver JDBC realiza advertencias o lanza excepciones DataTruncation como requier la especificación JDVC a no ser que la conexión se configure para no hacerlo con la propiedad "jdbcCompliantTruncation" a "false".
Las conversiones que siempre se garantizan que funcionan se muestran en la siguiente tabla:
Tabla 25.2. Tabla de conversiones
Estos tipos de datos MySQL | Siempre pueden convertirse en tipos de datos Java |
---|---|
CHAR, VARCHAR, BLOB, TEXT, ENUM, and SET |
java.lang.String, java.io.InputStream,
java.io.Reader, java.sql.Blob, java.sql.Clob
|
FLOAT, REAL, DOUBLE PRECISION, NUMERIC, DECIMAL, TINYINT, SMALLINT, MEDIUMINT, INTEGER, BIGINT | java.lang.String, java.lang.Short,
java.lang.Integer, java.lang.Long, java.lang.Double,
java.math.BigDecimal
Notapuede ocurrir redondeo, overflow o pérdida de precisión si elige tipos de datos numéricos Java que tengan menos precisión o capacidad que los tipos de datos MySQL que se convierten. |
DATE, TIME, DATETIME, TIMESTAMP |
java.lang.String, java.sql.Date,
java.sql.Timestamp
|
El método
ResultSet.getObject()
usa la siguiente conversión de tipos entre MySQL y tipos Java,
siguiendo la especificación JDBC donde es apropiado:
Tabla 25.3. Tipos MySQL para tiposJava Types para ResultSet.getObject()
Nombre de tipo MySQL | Retornado como Java Class |
---|---|
BIT(1) (nuevo en MySQL-5.0) |
java.lang.Boolean
|
BIT( > 1) (nuevo en MySQL-5.0) |
byte[]
|
TINYINT | java.lang.Boolean
si la propiedad de configuración "tinyInt1isBit"
está a "true" (por defecto) y el tamaño de
almacenamiento es "1", o
java.lang.Integer
si no. |
BOOL , BOOLEAN | Consulte TINYINT , anteriores son alias para TINYINT(1) , actualmente. |
SMALLINT[(M)] [UNSIGNED] | java.lang.Integer
(sea UNSIGNED o no) |
MEDIUMINT[(M)] [UNSIGNED] | java.lang.Integer
(sea UNSIGNED o no) |
INT,INTEGER[(M)] [UNSIGNED] | java.lang.Integer
, si UNSIGNED
java.lang.Long |
BIGINT[(M)] [UNSIGNED] | java.lang.Long
, si UNSIGNED
java.math.BigInteger |
FLOAT[(M,D)] |
java.lang.Float
|
DOUBLE[(M,B)] |
java.lang.Double
|
DECIMAL[(M[,D])] |
java.math.BigDecimal
|
DATE |
java.sql.Date
|
DATETIME |
java.sql.Timestamp
|
TIMESTAMP[(M)] |
java.sql.Timestamp
|
TIME |
java.sql.Time
|
YEAR[(2|4)] | java.sql.Date
(con la fecha a 1 de Enero, a media noche) |
CHAR(M) | java.lang.String
(a no ser que el conjunto de carácteres para la
columna sea
BINARY
, entonces se retorna
byte[]
. |
VARCHAR(M) [BINARY] | java.lang.String
(a no ser que el conjunto de carácteres para la
columna sea
BINARY
, entonces se retorna
byte[]
. |
BINARY(M) |
byte[]
|
VARBINARY(M) |
byte[]
|
TINYBLOB |
byte[]
|
TINYTEXT |
java.lang.String
|
BLOB |
byte[]
|
TEXT |
java.lang.String
|
MEDIUMBLOB |
byte[]
|
MEDIUMTEXT |
java.lang.String
|
LONGBLOB |
byte[]
|
LONGTEXT |
java.lang.String
|
ENUM('value1','value2',...) |
java.lang.String
|
SET('value1','value2',...) |
java.lang.String
|
Todas las cadenas de carácteres enviadas desde el driver JDBC
al servidor se convierten automáticament de Unicode nativo Java
a la codificación de carácteres del cliente, incluyendo todas
las consultas enviadas via
Statement.execute()
,
Statement.executeUpdate()
,
Statement.executeQuery()
así como
PreparedStatement
y parámetros
CallableStatement
con la exclusión de parámentros usando
setBytes()
,
setBinaryStream()
,
setAsiiStream()
,
setUnicodeStream()
y
setBlob()
.
Antes de MySQL Server 4.1, Connector/J soporta una codificación
de carácteres por conexión, que puede detectarse
automáticamente de la configuración del servidor, o puede
configurarse con las propiedades
useUnicode
y
characterEncoding
.
A partir de MySQL Server 4.1, Connector/J soporta una sóla
codificación de carácteres entre cliente y servidor, y
cualquier número de codificación de carácteres para datos
retornados por el servidor al cliente en
ResultSets
.
La codificación de carácteres entre cliente y servidor se
detecta automáticamente en la conexión. La codificación usada
por el driver se especifica en el servidor via la variable de
configuración '
character_set
' para versiones anteriores a 4.1.0 y '
character_set_server
' para versiones de servidor 4.1.0 y posteriores. Consulte
"Conunto
de carácteres del servidor y colaciones" en el manual
de servidor MySQL para más información.
Para aliminar la detección automática de codificación en el
cliente, use la propiedad
characterEncoding
en la URL usada para conectar al sevidor.
Cuando especifique codificaciones de carácteres en el cliente, deben usarse nombres de estilo Java. La siguiente tabla lista nombres de estilo Java para conjuntos de carácters MySQL:
Tabla 25.4. Traducción MySQL a nombres codificación Java
Nombre de conjunto de carácteres MySQL | Nombre codificación carácter estilo java Java |
---|---|
usa7 | US-ASCII |
big5 | Big5 |
gbk | GBK |
sjis | SJIS |
gb2312 | EUC_CN |
ujis | EUC_JP |
euc_kr | EUC_KR |
latin1 | ISO8859_1 |
latin1_de | ISO8859_1 |
german1 | ISO8859_1 |
danish | ISO8859_1 |
latin2 | ISO8859_2 |
czech | ISO8859_2 |
hungarian | ISO8859_2 |
croat | ISO8859_2 |
greek | ISO8859_7 |
hebrew | ISO8859_8 |
latin5 | ISO8859_9 |
latvian | ISO8859_13 |
latvian1 | ISO8859_13 |
estonia | ISO8859_13 |
dos | Cp437 |
pclatin2 | Cp852 |
cp866 | Cp866 |
koi8_ru | KOI8_R |
tis620 | TIS620 |
win1250 | Cp1250 |
win1250ch | Cp1250 |
win1251 | Cp1251 |
cp1251 | Cp1251 |
win1251ukr | Cp1251 |
cp1257 | Cp1257 |
macroman | MacRoman |
macce | MacCentralEurope |
utf8 | UTF-8 |
ucs2 | UnicodeBig |
Aviso
No realice la consulta 'set names' con Connector/J, ya que el driver no detectará que ha cambiado el conjunto de carácteres, y continuarña usando el conjunto de carácteres detectado durante la inicialización de la conexión.
Para permitir enviar múltiples conjuntos de carácters del
cliente, debe usarse codificación "UTF-8", configurando "utf8"
como el conjunto de carácteres por defecto del servidor, o
configurando el driver JDBC para usar "UTF-8" con la propiedad
characterEncoding
.
SSL en MySQL Connector/J encripta todos los datos (otros que no sean la negociación inicial) entre el driver JDBC y el servidor. La penalización al rendimiento para permitir SSL es un incremento en tiempo de proceso de consulta entre el 35% y el 50%, dependiendo del tamaño de la consulta, y la cantidad de datos que retorna.
Para que funcione el soporte SSL, debe tener lo siguiente:
-
JDK que incluya JSSE (Java Secure Sockets Extension), como JDK-1.4.1 o posterior. SSL no funciona con un JDK al que pueda añadir JSSE , como JDK-1.2.x o JDK-1.3.x debido al siguiente bug de JSSE : http://developer.java.sun.com/developer/bugParade/bugs/4273544.html
-
Un servidor MySQL que soporte SSL y se compile y configure para ello, que es MySQL-4.0.4 o posterior, consulte: http://www.mysql.com/doc/en/Secure_connections.html
-
Un certificado de cliente (cubierto posteriormente en esta sección)
Necesitará primeramente importar el certificado CA Certificate de MySQL en una entidad de confianza Java. Un certificado CA de ejemplo está en el subdirectorio 'SSL' de la distribución fuente de MySQL. Esto es lo que usa SSL para determinar si está comunicando con un servidor MySQL seguro.
Usar 'keytool' de Java para crear una entidad de confianza en el directorio actual, e importar el certificado CA del servidor ('cacert.pem'), puede hacer lo siguiente (asumiendo que 'keytool' está en su ruta. Está localizado en el subdirectorio 'bin' de su JDK o JRE):
shell> keytool -import -alias mysqlServerCACert -file cacert.pem -keystore truststore
Keytool responde con la siguiente información:
Enter keystore password: ********* Owner: [email protected], CN=Walrus, O=MySQL AB, L=Orenburg, ST=Some -State, C=RU Issuer: [email protected], CN=Walrus, O=MySQL AB, L=Orenburg, ST=Som e-State, C=RU Serial number: 0 Valid from: Fri Aug 02 16:55:53 CDT 2002 until: Sat Aug 02 16:55:53 CDT 2003 Certificate fingerprints: MD5: 61:91:A0:F2:03:07:61:7A:81:38:66:DA:19:C4:8D:AB SHA1: 25:77:41:05:D5:AD:99:8C:14:8C:CA:68:9C:2F:B8:89:C3:34:4D:6C Trust this certificate? [no]: yes Certificate was added to keystore
Necesitará generar un certificado de cliente, para que el servidor MySQL conozca que habla con un cliente seguro:
shell> keytool -genkey -keyalg rsa -alias mysqlClientCertificate -keystore keystore
Keytool le pide la siguiente información, y crea una llave llamada 'keystore' en el directorio actual.
Debe responder con información apropiada para su situación:
Enter keystore password: ********* What is your first and last name? [Unknown]: Matthews What is the name of your organizational unit? [Unknown]: Software Development What is the name of your organization? [Unknown]: MySQL AB What is the name of your City or Locality? [Unknown]: Flossmoor What is the name of your State or Province? [Unknown]: IL What is the two-letter country code for this unit? [Unknown]: US Is <CN=Matthews, OU=Software Development, O=MySQL AB, L=Flossmoor, ST=IL, C=US> correct? [no]: y Enter key password for <mysqlClientCertificate> (RETURN if same as keystore password):
Finalmente, para decir a JSSE que use la llave y entidad de confianza creadas, necesita asignar las siguientes propiedades de sistema cuando arranaca JVM, replazando 'path_to_keystore_file' con la ruta completa al fichero de la clave que ha creado, y usando la contraseña apropiada para cada propiedad.
-Djavax.net.ssl.keyStore=path_to_keystore_file -Djavax.net.ssl.keyStorePassword=********* -Djavax.net.ssl.trustStore=path_to_truststore_file -Djavax.net.ssl.trustStorePassword=*********
Necesita asignar a 'useSSL' 'true' en sus parámetros de conexión para MySQL Connector/J, añadiendo 'useSSL=true' a la URL, o poniendo la propiedad 'useSSL' a 'true' en la instancia java.util.Properties que pasa a DriverManager.getConnection().
Puede testear que SSL está funcionando activando la depuración de JSSE (como se detalla a contiunación), y buscar por los eventos clave siguientes:
... *** ClientHello, v3.1 RandomCookie: GMT: 1018531834 bytes = { 199, 148, 180, 215, 74, 12, 54, 244, 0, 168, 55, 103, 215, 64, 16, 138, 225, 190, 132, 153, 2, 217, 219, 239, 202, 19, 121, 78 } Session ID: {} Cipher Suites: { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 } Compression Methods: { 0 } *** [write] MD5 and SHA1 hashes: len = 59 0000: 01 00 00 37 03 01 3D B6 90 FA C7 94 B4 D7 4A 0C ...7..=.......J. 0010: 36 F4 00 A8 37 67 D7 40 10 8A E1 BE 84 99 02 D9 6...7g.@........ 0020: DB EF CA 13 79 4E 00 00 10 00 05 00 04 00 09 00 ....yN.......... 0030: 0A 00 12 00 13 00 03 00 11 01 00 ........... main, WRITE: SSL v3.1 Handshake, length = 59 main, READ: SSL v3.1 Handshake, length = 74 *** ServerHello, v3.1 RandomCookie: GMT: 1018577560 bytes = { 116, 50, 4, 103, 25, 100, 58, 202, 79, 185, 178, 100, 215, 66, 254, 21, 83, 187, 190, 42, 170, 3, 132, 110, 82, 148, 160, 92 } Session ID: {163, 227, 84, 53, 81, 127, 252, 254, 178, 179, 68, 63, 182, 158, 30, 11, 150, 79, 170, 76, 255, 92, 15, 226, 24, 17, 177, 219, 158, 177, 187, 143} Cipher Suite: { 0, 5 } Compression Method: 0 *** %% Created: [Session-1, SSL_RSA_WITH_RC4_128_SHA] ** SSL_RSA_WITH_RC4_128_SHA [read] MD5 and SHA1 hashes: len = 74 0000: 02 00 00 46 03 01 3D B6 43 98 74 32 04 67 19 64 ...F..=.C.t2.g.d 0010: 3A CA 4F B9 B2 64 D7 42 FE 15 53 BB BE 2A AA 03 :.O..d.B..S..*.. 0020: 84 6E 52 94 A0 5C 20 A3 E3 54 35 51 7F FC FE B2 .nR..\ ..T5Q.... 0030: B3 44 3F B6 9E 1E 0B 96 4F AA 4C FF 5C 0F E2 18 .D?.....O.L.\... 0040: 11 B1 DB 9E B1 BB 8F 00 05 00 .......... main, READ: SSL v3.1 Handshake, length = 1712 ...
JSSE proporciona depuración (a STDOUT) cuando asigna las siguientes propiedades de sistema: -Djavax.net.debug=all Este lo dice que claves y entidades de confianza se usan, así como que ocurre durante el intercambio SSL e intercambio de certificados. Será útil al determinar qué no está funcionando cuando se intenta realizar una conexión SSL.
A partir de Connector/J 3.1.7, está disponible una variante del
driver que envía automáticamente consultas a un maestro de
lectura/escritura, o un fallo o conjunto de esclavos con carga
balanceada mediante round-robin basado en el estado de
Connection.getReadOnly()
.
Una aplicación señala que quiere que una transacción sea
sólo de lectura llamando
Connection.setReadOnly(true)
, esta
conexión "avisada de replicación" usará una de las conexiones
esclavas, que están balanceadas por vm usando un esquema
round-robin (una conexión dada se "pega" a un esclavo a no ser
que se quite al esclavo del servicio). Si tiene una transacción
de lectura, la replicación de MySQL es asíncrona), asigne que
la conexión no sea sólo de lectura, llamando
Connection.setReadOnly(false)
y el driver
se asegura que las siguientes llamadas se envíen al sevidor
MySQL "maestro". El driver tiene cuidado de propagar el estado
actual de autocommit, nivel de isolación, y catálogos entre
todas las conexiones que usa para complir la funcionalidad de
balanceo de carga.
Para activar esta funcionalidad, use la clase "
com.mysql.jdbc.ReplicationDriver
" al
configurar su pool de conexiones del servidor de aplicaciones o
al crear una instancia de un driver JDBC para su aplicación
autónoma. Como acepta el mismo formato de URL que el driver
estándar JDBC MySQL, ReplicationDriver
no
funciona con creación de conexiones basadas en
java.sql.DriverManager
a no ser que sea el
único driver JDBC de MySQL registrado con
DriverManager
.
Aquí hay un pequeño ejemplo sobre cómo puede usarse ReplicationDriver en una aplicación autónoma.
import java.sql.Connection; import java.sql.ResultSet; import java.util.Properties; import com.mysql.jdbc.ReplicationDriver; public class ReplicationDriverDemo { public static void main(String[] args) throws Exception { ReplicationDriver driver = new ReplicationDriver(); Properties props = new Properties(); // We want this for failover on the slaves props.put("autoReconnect", "true"); // We want to load balance between the slaves props.put("roundRobinLoadBalance", "true"); props.put("user", "foo"); props.put("password", "bar"); // // Looks like a normal MySQL JDBC url, with a comma-separated list // of hosts, the first being the 'master', the rest being any number // of slaves that the driver will load balance against // Connection conn = driver.connect("jdbc:mysql://master,slave1,slave2,slave3/test", props); // // Perform read/write work on the master // by setting the read-only flag to "false" // conn.setReadOnly(false); conn.setAutoCommit(false); conn.createStatement().executeUpdate("UPDATE some_table ...."); conn.commit(); // // Now, do a query from a slave, the driver automatically picks one // from the list // conn.setReadOnly(true); ResultSet rs = conn.createStatement().executeQuery("SELECT a,b,c FROM some_other_table"); ....... } }
Esta sección describe cómo usar Connector/J en varios contextos.
Esta sección proporciona transfondo general de conceptos de J2EE que usan el Connector/J.
Crear pools de conexiones es la técnica de crear y administrar un conjunto de conexiones preparados para usar por cualquier flujo que lo necesite.
La técnica de "pooling" conexiones se basa en el hecho que la mayoría de aplicaciones sólo necesitan que un flujo tenga acceso a una conexión JDBC cuando procesan activamente una transacción, lo que usualmente sólo tarda milisegundos en completarse. Cuando no procesan una transacción, la conexión queda en espera. En su lugar, un pool de conexiones permite que la conexión inactiva sea usada por otro flujo para hacer trabajo útil.
En la práctica, cuando un flujo necesita trabajar contra MySQL u otra base de datos con JDBC, pide una conexión al pool. Cuando el flujo finaliza el uso de la conexión, la retorna el pool para que pueda ser usada por cualquier otro flujo que la necesite.
Cuando una conexión se "alquila" en el pool, la usa únicamente el flujo que la pide. Desde un punto de vista de programación, es lo mismo que si su flujo llame a DriverManager.getConnection() cada vez que necesite una conexión JDBC, sin embargo con el pool de conexiones, su flujo puede acabar usando una conexión nueva o ya existente.
Los pool de conexiones pueden incrementar el rendimiento de su aplicación Java, y reducir el uso de recursos global. Los mayores beneficios de los pool de conexiones son:
-
Reducir el tiempo de creación de conexiones
Aunque normalmente no es un tema proecupante ya que MySQL ofrece un tiempo de incialización rápido en comparación con otras bases de datos, la creación de conexiones JDBC todavía incurre en la sobrecarga de red y conexiones JDBC que se eliminan si se "reciclan" las conexiones.
-
Modelo de programación simplificado
Usando pools de conexiones, cada flujo individual puede actuar como si hubiese creado su propia conexión JDBC, permitiendo usar ténicas de programación JDBC directas.
-
Uso de recursos controlado
Si no usa pools de conexiones, y en su lugar crea una nueva conexión cada vez que un flujo necesita una, su uso de recursos por parte de la aplicación puede ser muy derrochador y puede llevar a comportamiento impredictible bajo carga.
Recuerde que cada conexión de MySQL tiene sobrecarga (memoria, CPU, cambios de contexto, etc) tanto en el cliente como en el servidor. Cada conexión limita los recursos disponible para su aplicación así como el servidor MySQL. Muchos de estos recursos se usarán tanto si la conexión está haciendo un trabajo útil como si no!
Los pools de conexiones pueden ajustarse para maximizar el rendimiento, mientras que mantienen la utilización de recursos bajo el punto en que su aplicación empieza a fallar en lugar de sólo ir más lenta.
Afortunadamente, Sun ha estandarizado el concepto de pool de conexiones en JDBC a través de las interficies "opcionales" JDBC-2.0 y todos los servidores de aplicaciones tienen implementaciones de estas APIs que funcionan bien con MySQL Connector/J.
Generalmente, usted configura un pool de conexiones en su servidor de aplicaciones en sus ficheros de configuración del servidor, y accede via el Java Naming y Directory Interface (JNDI). El siguiente código muestra cómo puede usar un pool de conexiones desde una aplicación desplegada en un servidor de aplicaciones J2EE:
Ejemplo 25.12. Usando un pool de conexiones con un servidor de aplicaciones J2EE
import java.sql.Connection; import java.sql.SQLException; import java.sql.Statement; import javax.naming.InitialContext; import javax.sql.DataSource; public class MyServletJspOrEjb { public void doSomething() throws Exception { /* * Create a JNDI Initial context to be able to * lookup the DataSource * * In production-level code, this should be cached as * an instance or static variable, as it can * be quite expensive to create a JNDI context. * * Note: This code only works when you are using servlets * or EJBs in a J2EE application server. If you are * using connection pooling in standalone Java code, you * will have to create/configure datasources using whatever * mechanisms your particular connection pooling library * provides. */ InitialContext ctx = new InitialContext(); /* * Lookup the DataSource, which will be backed by a pool * that the application server provides. DataSource instances * are also a good candidate for caching as an instance * variable, as JNDI lookups can be expensive as well. */ DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/MySQLDB"); /* * The following code is what would actually be in your * Servlet, JSP or EJB 'service' method...where you need * to work with a JDBC connection. */ Connection conn = null; Statement stmt = null; try { conn = ds.getConnection(); /* * Now, use normal JDBC programming to work with * MySQL, making sure to close each resource when you're * finished with it, which allows the connection pool * resources to be recovered as quickly as possible */ stmt = conn.createStatement(); stmt.execute("SOME SQL QUERY"); stmt.close(); stmt = null; conn.close(); conn = null; } finally { /* * close any jdbc instances here that weren't * explicitly closed during normal code path, so * that we don't 'leak' resources... */ if (stmt != null) { try { stmt.close(); } catch (sqlexception sqlex) { // ignore -- as we can't do anything about it here } stmt = null; } if (conn != null) { try { conn.close(); } catch (sqlexception sqlex) { // ignore -- as we can't do anything about it here } conn = null; } } } }
Como se muestra en el ejemplo anterior, tras obtener el JNDI InitialContext, y buscar en el DataSource, el resto del código debe parecer familiar a cualquiera que haya programado JDBC en el pasado.
Lo más importante a recordar al usar pools de conexiones es asegurarse que no importa qué ocurra en su código (excepciones, control de flujo, etc), conexiones, y cualquier cosa creada por ellas (comandos, conjuntos de resultados, etc) se cierran, así que pueden ser reusados, de otro modo serán "trenzados", lo que en el mejor caso significa que los recursos que el servidor MySQL representa (búffers, bloqueos, sockets, etc) pueden quedar atados por algún tiempo, o en el peor de los casos, atados para siempre.
¿Cuál es el mejor tamaño para mi pool de conexiones?
Como con todas las otras reglas de configuración, la respuesta es "depende". Mientras el tamaño óptimo depende de carga anticipada y tiempo medio de transacción de la base de datos, el tamaño del pool de conexiones óptimo es menor de lo que podría esperar. Si toma la aplicación de Sun Java Petstore de ejemplo, un pool de conexiones de 15-20 conexiones puede servir una carga moderada (600 usuarios concurrentes) usando MySQL y Tomcat con tiempos de respuesta aceptables.
Para poner el tamaño correcto en un pool de conexiones para su aplicación, debe crear tests de carga con herramientas como Apache JMeter o The Grinder, y testear su aplicación.
Una forma sencilla de determinar un punto de inicio es configurar su pool de conexión con un número máximo de conexiones "ilimitado", ejecutar un test de carga, y medir el máximo número de conexiones de usuario concurrentes. Puede trabajar a partir de aquí para determinar los valores de conexiones máximo y mínimo dado el mejor rendimiento de su aplicación.
Las siguientes instrucciones se basan en las instrucciones para Tomcat-5.x, disponibles en http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html que es la actual en el momento de escritura de este documento.
Primero, instale el fichero .jar que viene con Connector/J en
$CATALINA_HOME/common/lib
para que esté
disponible para todas las aplicaciones instaladas en el
contenedor.
A continuación, Configure JNDI DataSource añadiendo una
declaración de recurso en
$CATALINA_HOME/conf/server.xml
en el
contexto que define su aplicación web:
<Context ....> ... <Resource name="jdbc/MySQLDB" auth="Container" type="javax.sql.DataSource"/> <!-- The name you used above, must match _exactly_ here! The connection pool will be bound into JNDI with the name "java:/comp/env/jdbc/MySQLDB" --> <ResourceParams name="jdbc/MySQLDB"> <parameter> <name>factory</name> <value>org.apache.commons.dbcp.BasicDataSourceFactory</value> </parameter> <!-- Don't set this any higher than max_connections on your MySQL server, usually this should be a 10 or a few 10's of connections, not hundreds or thousands --> <parameter> <name>maxActive</name> <value>10</value> </parameter> <!-- You don't want to many idle connections hanging around if you can avoid it, only enough to soak up a spike in the load --> <parameter> <name>maxIdle</name> <value>5</value> </parameter> <!-- Don't use autoReconnect=true, it's going away eventually and it's a crutch for older connection pools that couldn't test connections. You need to decide if your application is supposed to deal with SQLExceptions (hint, it should), and how much of a performance penalty you're willing to pay to ensure 'freshness' of the connection --> <parameter> <name>validationQuery</name> <value>SELECT 1</value> </parameter> <!-- The most conservative approach is to test connections before they're given to your application. For most applications this is okay, the query used above is very small and takes no real server resources to process, other than the time used to traverse the network. If you have a high-load application you'll need to rely on something else. --> <parameter> <name>testOnBorrow</name> <value>true</value> </parameter> <!-- Otherwise, or in addition to testOnBorrow, you can test while connections are sitting idle --> <parameter> <name>testWhileIdle</name> <value>true</value> </parameter> <!-- You have to set this value, otherwise even though you've asked connections to be tested while idle, the idle evicter thread will never run --> <parameter> <name>timeBetweenEvictionRunsMillis</name> <value>10000</value> </parameter> <!-- Don't allow connections to hang out idle too long, never longer than what wait_timeout is set to on the server...A few minutes or even fraction of a minute is sometimes okay here, it depends on your application and how much spikey load it will see --> <parameter> <name>minEvictableIdleTimeMillis</name> <value>60000</value> </parameter> <!-- Username and password used when connecting to MySQL --> <parameter> <name>username</name> <value>someuser</value> </parameter> <parameter> <name>password</name> <value>somepass</value> </parameter> <!-- Class name for the Connector/J driver --> <parameter> <name>driverClassName</name> <value>com.mysql.jdbc.Driver</value> </parameter> <!-- The JDBC connection url for connecting to MySQL, notice that if you want to pass any other MySQL-specific parameters you should pass them here in the URL, setting them using the parameter tags above will have no effect, you will also need to use & to separate parameter values as the ampersand is a reserved character in XML --> <parameter> <name>url</name> <value>jdbc:mysql://localhost:3306/test</value> </parameter> </ResourceParams> </Context>
En general, debe usar las instrucciones de instalación que vienen con su versión de Tomcat, ya que la forma de configurar fuentes de datos en Tomcat cambian de vez en cuando, y si usa la sintaxis equivocada en el fichero XML, puede acabar con una excepción similar a la siguiente:
Error: java.sql.SQLException: Cannot load JDBC driver class 'null ' SQL state: null
Estas instrucciones cubren JBoss-4.x. Para hacer que las clases
del driver JDBC estén disponibles para el servidor de
aplicaciones, copie el fichero .jar que viene con el Connector/J
en el directorio lib
para su configuración
del servidor (normalmente llamada
"default
"). A continuación, en el mismo
directorio de configuración, en el subdirectorio llamado
"deploy", cree un fichero de configuración de fuente de datos
que acabe con "-ds.xml", que le dice a JBoss que despliegue este
fichero como JDBC Datasource. El fichero debe tener el siguiente
contenido:
<datasources> <local-tx-datasource> <!-- This connection pool will be bound into JNDI with the name "java:/MySQLDB" --> <jndi-name>MySQLDB</jndi-name> <connection-url>jdbc:mysql://localhost:3306/dbname</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>user</user-name> <password>pass</password> <min-pool-size>5</min-pool-size> <!-- Don't set this any higher than max_connections on your MySQL server, usually this should be a 10 or a few 10's of connections, not hundreds or thousands --> <max-pool-size>20</max-pool-size> <!-- Don't allow connections to hang out idle too long, never longer than what wait_timeout is set to on the server...A few minutes is usually okay here, it depends on your application and how much spikey load it will see --> <idle-timeout-minutes>5</idle-timeout-minutes> <!-- If you're using Connector/J 3.1.8 or newer, you can use our implementation of these to increase the robustness of the connection pool. --> <exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name> <valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name> </local-tx-datasource> </datasources>
Esta sección describe cómo arreglar problemas que puede encontrar al usar Connector/J.
Hay algunos temas que parecen encontrar los usuarios de MySQL Connector/J. Esta sección trata sus síntomas y su resolución. Si tiene otros problemas, consulte la sección "SOPORTE".
26.3.5.1.1:
Question:
Cuando intento conectar a la base de datos con MySQL Connector/J, obtengo la siguiente excepción:
SQLException: Server configuration denies access to data source SQLState: 08001 VendorError: 0
¿Qué ocurre? Puede conectar bien con el cliente de línea de comandos de MySQL.
Answer:
MySQL Connector/J usa sockets TCP/IP para conectar a MySQL, ya que Java no soporta Unix Domain Sockets. Por lo tanto, cuando MySQL Connector/J conecta a MySQL, el administrador de seguridad en el servidor MySQL usará sus tablas de permisos para determinar si la conexión debe permitirse.
Debe añadir permisos para permitir esto. Lo siguiente es un ejemplo de cómo hacerlo (pero no es lo más seguro).
Desde el cliente de línea de comandos, logueado como usuario que pueda otorgar privilegios, ejecute el siguiente comando:
GRANT ALL PRIVILEGES ON [dbname].* to '[user]'@'[hostname]' identified by '[password]'
reemplazando [dbname] con el nombre de su base de datos, [user] con el nombre de usuario, [hostname] con el equipo desde el que se conecta MySQL Connector/J , y [password] con la contraseña que quiere usar. Tenga en cuenta que RedHat Linux está roto respecto a la porción de nombre de equipo para el caso en que conecte desde el equipo local. Necesita usar "localhost.localdomain" para el valor [hostname] en este caso. A continuación ejecute el comando "FLUSH PRIVILEGES".
Nota
Compruebe su conectividad con el cliente de línea de comandos "mysql", pero no funcionará a no ser que añada el flag "--host" y use un valor distinto a "localhost" para el equipo. Si está testeando la conectividad con "localhost", use "127.0.0.1" como nombre de equipo.
Aviso
Si no entiende lo que hace el comando 'GRANT' o cómo funciona, debe leer y entender la sección 'Temas generales de seguridad y el sistema de privilegios de acceso de MySQL' del manual MySQL antes de intentar cambiar los premisos.
Cambiar privilegios y permisos de forma no correcta en MySQL puede causar que su instalación no tenga propiedades de seguridad óptimas.
26.3.5.1.2:
Question:
Mi aplicación lanza una SQLException 'No Suitable Driver'. ¿Qué ocurre?
Answer:
Pueden ser dos cosas. O el driver no está en su CLASSPATH (consulte la sección "INSTALACIÓN" anterior), o su formato de URL no es correcto (consulte "Desarrollo de aplicaciones con MySQL Connector/J").
26.3.5.1.3:
Question:
Intento usar MySQL Connector/J en un applet o aplicación y obtengo una excepción similar a:
SQLException: Cannot connect to MySQL server on host:3306. Is there a MySQL server running on the machine/port you are trying to connect to? (java.security.AccessControlException) SQLState: 08S01 VendorError: 0
Answer:
Incluso si está ejecutando un Applet, su MySQL server ha sido instalado con la opción "--skip-networking" activada, o su MySQL server tiene un firewall delante.
Applets sólo pueden hacer conexiones de red de vuelta a la máquina que ejecuta el servidor web que sirve los ficheros .class para el applet. Esto significa que MySQL debe ejecutarse en la misma máquina (o debe tener alguna clase de redirección de puertos) para que funcione. También significa que no será capaz de testear applets en su sistema de ficheros local, siempre debe desplegarlos en un servidor web.
MySQL Connector/J sólo puede comunicar con MySQL usando TCP/IP, ya que Java no soporta sockets de dominio Unix. La comunicación TCP/IP con MySQL puede verse afectada si MySQL se arranca con el flag "--skip-networking" , o si tiene un firewall.
Si MySQL se arranca con la opción "--skip-networking" activada (el paquete Debian Linux de MySQL server lo hace, por ejemplo), necesita comentarlo en los ficheros /etc/mysql/my.cnf o /etc/my.cnf. Por supuesto, su fichero my.cnf puede existir en el directorio "data" de su MySQL server, o en cualquier otro sitio (en función de cómo se compiló MySQL en su sistema). Los binarios creados por MySQL AB siempre buscan en /etc/my.cnf y [datadir]/my.cnf. Si su MySQL tiene un firewall, necesitará tener el firewall configurado para permitir conexiones TCP/IP desde el equipo donde el código Java está corriendo al servidor MySQL en el puerto en el que está escuchando MySQL (por defecto 3306).
26.3.5.1.4:
Question:
Tengo un servlet/aplicación que funciona bien durante un día y para de funcionar por la noche
Answer:
MySQL cierra las conexiones tras 8 horas de inactividad. Necesita usar un pool de conexiones que trate conexiones en espera o use el parámetro "autoReconnect" (consulte "Desarrollo de aplicaciones con MySQL Connector/J").
Además, debe cachear SQLExceptions en su aplicación y tratarlas, en lugar de propagarlas hasta que acaba la aplicación, esto es sólo una buena práctica de programación. MySQL Connector/J actualiza el SQLState (cosulte java.sql.SQLException.getSQLState() en sus APIDOCS) a "08S01" cuando encuentra problemas de conectividad de red durante el procesamiento de una consulta. Su código de aplicación debe tratar de reconectar a MySQL en este punto.
El siguiente ejemplo (simple) muestra cómo debería ser el código que trata estas excepciones:
Ejemplo 25.13. Ejemplo de transacción con lógica de reintento
public void doBusinessOp() throws SQLException { Connection conn = null; Statement stmt = null; ResultSet rs = null; // // How many times do you want to retry the transaction // (or at least _getting_ a connection)? // int retryCount = 5; boolean transactionCompleted = false; do { try { conn = getConnection(); // assume getting this from a // javax.sql.DataSource, or the // java.sql.DriverManager conn.setAutoCommit(false); // // Okay, at this point, the 'retry-ability' of the // transaction really depends on your application logic, // whether or not you're using autocommit (in this case // not), and whether you're using transacational storage // engines // // For this example, we'll assume that it's _not_ safe // to retry the entire transaction, so we set retry count // to 0 at this point // // If you were using exclusively transaction-safe tables, // or your application could recover from a connection going // bad in the middle of an operation, then you would not // touch 'retryCount' here, and just let the loop repeat // until retryCount == 0. // retryCount = 0; stmt = conn.createStatement(); String query = "SELECT foo FROM bar ORDER BY baz"; rs = stmt.executeQuery(query); while (rs.next()) { } rs.close(); rs = null; stmt.close(); stmt = null; conn.commit(); conn.close(); conn = null; transactionCompleted = true; } catch (SQLException sqlEx) { // // The two SQL states that are 'retry-able' are 08S01 // for a communications error, and 41000 for deadlock. // // Only retry if the error was due to a stale connection, // communications problem or deadlock // String sqlState = sqlEx.getSQLState(); if ("08S01".equals(sqlState) || "41000".equals(sqlState)) { retryCount--; } else { retryCount = 0; } } finally { if (rs != null) { try { rs.close(); } catch (SQLException sqlEx) { // You'd probably want to log this . . . } } if (stmt != null) { try { stmt.close(); } catch (SQLException sqlEx) { // You'd probably want to log this as well . . . } } if (conn != null) { try { // // If we got here, and conn is not null, the // transaction should be rolled back, as not // all work has been done try { conn.rollback(); } finally { conn.close(); } } catch (SQLException sqlEx) { // // If we got an exception here, something // pretty serious is going on, so we better // pass it up the stack, rather than just // logging it. . . throw sqlEx; } } } } while (!transactionCompleted && (retryCount > 0)); }
26.3.5.1.5:
Question:
Intento usar conjuntos de resultados actualizables de JDBC-2.0, y obtengo una excepción diciendo que mi conjunto de resultados no es actualizable.
Answer:
Debido a que MySQL no tiene identificadores de registros, MySQL Connector/J sólo puede actualizar conjuntos de resultados que vengan de consultas en tablas que tengan como mínimo una clave primaria, la consulta debe seleccionar todos los campos de la clave(s) primaria y la consulta sólo puede consultar una tabla (no joins). Esto se explica en la especificación JDBC.
El sitio normal en el que reportar bugs es http://bugs.mysql.com/, que es la dirección de nuestra base de datos de bugs. Esta base de datos es pública, y puede ser consultada por cualquiera. Si se loguea en el sistema, debe ser capaz de introducir nuevos reportes.
Si encuentra un error de seguridad sensible en MySSQL, puede enviar un correo a [email protected].
Escribir un buen reporte de bug necesita de paciencia, pero hacerlo bien la primera vez nos ahorra tiempo tanto a nosotros como a usted. Un buen reporte de bug, conteniendo un test de casos completo para el bug, hace que sea muy probable que arreglemos el bug en la siguiente versión.
Esta sección le ayuda a escribir un reporte correctamente para que no pierda tiempo haciendo cosas que no nos ayudan.
Si tiene un reporte de un bug repetible, por favor repórtelo a la base de datos de bugs en http://bugs.mysql.com/.
Cualquier bug que seamos capaces de repetir tiene una alta probabilidad que lo arreglemos en la siguiente versión de MySQL.
Para reportar otros problemas, puede usar una de las listas de correo de MySQL.
Recuerde que es posible para nosotros responder un mensaje que contenga demasiada información, pero no a uno que no contenga suficiente. La gente normalmente omite hechos porque piensan que saben la causa del problema y asumen que algunos detalles no importan.
Un buen principio es el siguiente: si duda acerca de reportar algo, repórtelo. Es más rápido y menso problemático escribir un par de líneas extra en su reporte que esperar la respuesta si debemos pedir que proporcione información no presente en el reporte inicial.
Los errores más comunes en los reportes de bugs son (a) no incluir el número de versión de Connector/J o MySQL usados, y (b) no describir completamente la plataforma donde el Connector/J está instalado (incluyendo la versión de la JVM , y el tipo de plataforma y versión de donde el propio MySQL está instalado).
Esta es información altamente relevante, y en el 99% de los casos el reporte de bug no es útil sin ella. Muy a menudo obtenemos preguntas como "¿Porqué no me funciona a mi?" luego encontramos que la característica pedida no estaba implementada en esa versión de MySQL, o que el bug descrito en el reporte se ha arreglado en versiones posteriores de MySQL.
A veces el error depende de la plataforma; en tales casos, es casi imposible para nosotros arreglar nada sin saber el sistema operativo y el número de versión de la platagorma.
Si es posible, debe crear un caso de uso repetible que no incluya clases de terceras partes.
Para facilitar este proceso, proporcionamos una clase base para
tests de uso con Connector/J, llamado '
com.mysql.jdbc.util.BaseBugReport
'. Para crear un caso de uso para Connector/J usando esta clase,
cree su propia clase que herede de
com.mysql.jdbc.util.BaseBugReport
y sobreescriba los métodos setUp()
,
tearDown()
y
runTest
().
En el método setUp()
, cree código
que cree sus tablas y añada los datos necesarios para demostrar
el bug.
En el método runTest
() , cree código
que demuestre el bug usando la tablas y datos creados en el
método 'setUp' .
En el método tearDown()
, borre
cualquier tabla creada en el método
setUp()
.
En cualquiera de los tres métodos anteriores, debe usar una de
las variantes del método getConnection
() para crear una conexión JDBC para MySQL:
-
getConnection() - Proporciona una conexión para la JDBC URL especificada en getUrl(). Si una conexión ya existe, esa conexión se retorna, de otro modo se crea una nueva conexión.
-
getNewConnection() - Use esto si necesita obtener una nueva conexión para su reporte de bug(p.e. hay más de una conexión involucrada).
-
getConnection(String url) - Retorna una conexión usando una URL dada.
-
getConnection(String url, Properties props) - Retorna una conexión usando la URL y propiedades dadas.
Si necesita usar una URL JDBC diferente a 'jdbc:mysql:///test',
sobreescriba también el método
getUrl()
.
Use los métodos assertTrue(boolean
expression)
y assertTrue(String
failureMessage, boolean expression)
para crear
condiciones que deben existir en su demostración de casos de
uso para el comportamiento que espera ( el comportamiento que
observa, que es por lo que está rellenando un reporte de bug).
Finalmente, cree un método main
() que
cree una nueva instancia en su caso de uso, y llame al método
run
:
public static void main(String[] args) throws Exception { new MyBugReport().run(); }
Cuando haya acabado su caso de uso, y haya verificado que demuestra el bug que está reportando, súbalo con su reporte de bug a http://bugs.mysql.com/.
# Changelog # $Id: CHANGES,v 1.38.4.206 2005/05/12 15:25:54 mmatthews Exp $ 05-17-05 - Version 3.2.1-alpha - Autoreconnect functionality (i.e. autoReconnect=true) is now deprecated. An exception will be thrown if you try and use it, use 'enableDeprecatedAutoreconnect=true' to still use autoReconnect. However this feature will be removed in Connector/J 3.3, see the manual for solutions that don't require autoReconnect to be used. - Driver now checks if server variable 'init_connect' is set, and if so checks autocommit setting, and applies it. - If connected to server > 5.0.x, and Statement.setFetchSize( > 0), the driver will try and use server prepared statements and fetch statements using result set 'cursors'. - ServerPreparedStatements now correctly 'stream' BLOB/CLOB data to the server. You can configure the threshold chunk size using the JDBC URL property 'blobSendChunkSize' (the default is one megabyte). - Support sql mode NO_BACKSLASH_ESCAPES with non-server-side prepared statements. 12-23-04 - Version 3.2.0-alpha - Fixed incorrect return values from DatabaseMetaData.supportsCatalogIn*(). - Support for 'cursor' based result sets when using ServerPreparedStatements and MySQL 5.0 or newer. Result set needs to be forward-only, and a non-zero fetch size for this feature to be enabled. - Refactoring of where logic for prepared statement, server-prepared statement lives. 10-07-05 - Version 3.1.11-stable - Fixed BUG#11629 - Spurious "!" on console when character encoding is "utf8". - Fixed statements generated for testcases missing ";" for "plain" statements. - Fixed BUG#11663 - Incorrect generation of testcase scripts for server-side prepared statements. - Fixed regression caused by fix for BUG#11552 that caused driver to return incorrect values for unsigned integers when those integers where within the range of the positive signed type. - Moved source code to svn repo. - Fixed BUG#11797 - Escape tokenizer doesn't respect stacked single quotes for escapes. - GEOMETRY type not recognized when using server-side prepared statements. - Fixed BUG#11879 -- ReplicationConnection won't switch to slave, throws "Catalog can't be null" exception. - Fixed BUG#12218, properties shared between master and slave with replication connection. - Fixed BUG#10630, Statement.getWarnings() fails with NPE if statement has been closed. - Only get char[] from SQL in PreparedStatement.ParseInfo() when needed. - Fixed BUG#12104 - Geometry types not handled with server-side prepared statements. - Fixed BUG#11614 - StringUtils.getBytes() doesn't work when using multibyte character encodings and a length in _characters_ is specified. - Fixed BUG#11798 - Pstmt.setObject(...., Types.BOOLEAN) throws exception. - Fixed BUG#11976 - maxPerformance.properties mis-spells "elideSetAutoCommits". - Fixed BUG#11575 -- DBMD.storesLower/Mixed/UpperIdentifiers() reports incorrect values for servers deployed on Windows. - Fixed BUG#11190 - ResultSet.moveToCurrentRow() fails to work when preceeded by a call to ResultSet.moveToInsertRow(). - Fixed BUG#11115, VARBINARY data corrupted when using server-side prepared statements and .setBytes(). - Fixed BUG#12229 - explainSlowQueries hangs with server-side prepared statements. - Fixed BUG#11498 - Escape processor didn't honor strings demarcated with double quotes. - Lifted restriction of changing streaming parameters with server-side prepared statements. As long as _all_ streaming parameters were set before execution, .clearParameters() does not have to be called. (due to limitation of client/server protocol, prepared statements can not reset _individual_ stream data on the server side). - Reworked Field class, *Buffer, and MysqlIO to be aware of field lengths > Integer.MAX_VALUE. - Updated DBMD.supportsCorrelatedQueries() to return true for versions > 4.1, supportsGroupByUnrelated() to return true and getResultSetHoldability() to return HOLD_CURSORS_OVER_COMMIT. - Fixed BUG#12541 - Handling of catalog argument in DatabaseMetaData.getIndexInfo(), which also means changes to the following methods in DatabaseMetaData: - getBestRowIdentifier() - getColumns() - getCrossReference() - getExportedKeys() - getImportedKeys() - getIndexInfo() - getPrimaryKeys() - getProcedures() (and thus indirectly getProcedureColumns()) - getTables() The "catalog" argument in all of these methods now behaves in the following way: - Specifying NULL means that catalog will not be used to filter the results (thus all databases will be searched), unless you've set "nullCatalogMeansCurrent=true" in your JDBC URL properties. - Specifying "" means "current" catalog, even though this isn't quite JDBC spec compliant, it's there for legacy users. - Specifying a catalog works as stated in the API docs. - Made Connection.clientPrepare() available from "wrapped" connections in the jdbc2.optional package (connections built by ConnectionPoolDataSource instances). - Added Connection.isMasterConnection() for clients to be able to determine if a multi-host master/slave connection is connected to the first host in the list. - Fixed BUG#12753 - Tokenizer for "=" in URL properties was causing sessionVariables=.... to be parameterized incorrectly. - Fixed BUG#11781, foreign key information that is quoted is parsed incorrectly when DatabaseMetaData methods use that information. - The "sendBlobChunkSize" property is now clamped to "max_allowed_packet" with consideration of stream buffer size and packet headers to avoid PacketTooBigExceptions when "max_allowed_packet" is similar in size to the default "sendBlobChunkSize" which is 1M. - CallableStatement.clearParameters() now clears resources associated with INOUT/OUTPUT parameters as well as INPUT parameters. - Fixed BUG#12417 - Connection.prepareCall() is database name case-sensitive (on Windows systems). - Fixed BUG#12752 - Cp1251 incorrectly mapped to win1251 for servers newer than 4.0.x. - Fixed BUG#12970 - java.sql.Types.OTHER returned for BINARY and VARBINARY columns when using DatabaseMetaData.getColumns(). - ServerPreparedStatement.getBinding() now checks if the statement is closed before attempting to reference the list of parameter bindings, to avoid throwing a NullPointerException. - Fixed BUG#13277 - ResultSetMetaData from Statement.getGeneratedKeys() caused NullPointerExceptions to be thrown whenever a method that required a connection reference was called. - Backport of Field class, ResultSetMetaData.getColumnClassName(), and ResultSet.getObject(int) changes from 5.0 branch to fix behavior surrounding VARCHAR BINARY/VARBINARY and related types. - Fixed NullPointerException when converting "catalog" parameter in many DatabaseMetaDataMethods to byte[]s (for the result set) when the parameter is null. ("null" isn't technically allowed by the JDBC specification, but we've historically allowed it). - Backport of VAR[BINARY|CHAR] [BINARY] types detection from 5.0 branch. - Read response in MysqlIO.sendFileToServer(), even if the local file can't be opened, otherwise next query issued will fail, because it's reading the response to the empty LOAD DATA INFILE packet sent to the server. - Workaround for BUG#13374 - ResultSet.getStatement() on closed result set returns NULL (as per JDBC 4.0 spec, but not backwards-compatible). Set the connection property "retainStatementAfterResultSetClose" to "true" to be able to retrieve a ResultSet's statement after the ResultSet has been closed via .getStatement() (the default is "false", to be JDBC-compliant and to reduce the chance that code using JDBC leaks Statement instances). - Fixed BUG#13453 - URL configuration parameters don't allow '&' or '=' in their values. The JDBC driver now parses configuration parameters as if they are encoded using the application/x-www-form-urlencoded format as specified by java.net.URLDecoder - http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLDecoder.html If the '%' character is present in a configuration property, it must now be represented as %25, which is the encoded form of '%' when using application/x-www-form-urlencoded encoding. - The configuration property "sessionVariables" now allows you to specify variables that start with the "@" sign. - Fixed BUG#13043 - when 'gatherPerfMetrics' is enabled for servers older than 4.1.0, a NullPointerException is thrown from the constructor of ResultSet if the query doesn't use any tables. 06-23-05 - Version 3.1.10-stable - Fixed connecting without a database specified raised an exception in MysqlIO.changeDatabaseTo(). - Initial implemention of ParameterMetadata for PreparedStatement.getParameterMetadata(). Only works fully for CallableStatements, as current server-side prepared statements return every parameter as a VARCHAR type. 06-22-05 - Version 3.1.9-stable - Overhaul of character set configuration, everything now lives in a properties file. - Driver now correctly uses CP932 if available on the server for Windows-31J, CP932 and MS932 java encoding names, otherwise it resorts to SJIS, which is only a close approximation. Currently only MySQL-5.0.3 and newer (and MySQL-4.1.12 or .13, depending on when the character set gets backported) can reliably support any variant of CP932. - Fixed BUG#9064 - com.mysql.jdbc.PreparedStatement.ParseInfo does unnecessary call to toCharArray(). - Fixed Bug#10144 - Memory leak in ServerPreparedStatement if serverPrepare() fails. - Actually write manifest file to correct place so it ends up in the binary jar file. - Added "createDatabaseIfNotExist" property (default is "false"), which will cause the driver to ask the server to create the database specified in the URL if it doesn't exist. You must have the appropriate privileges for database creation for this to work. - Fixed BUG#10156 - Unsigned SMALLINT treated as signed for ResultSet.getInt(), fixed all cases for UNSIGNED integer values and server-side prepared statements, as well as ResultSet.getObject() for UNSIGNED TINYINT. - Fixed BUG#10155, double quotes not recognized when parsing client-side prepared statements. - Made enableStreamingResults() visible on com.mysql.jdbc.jdbc2.optional.StatementWrapper. - Made ServerPreparedStatement.asSql() work correctly so auto-explain functionality would work with server-side prepared statements. - Made JDBC2-compliant wrappers public in order to allow access to vendor extensions. - Cleaned up logging of profiler events, moved code to dump a profiler event as a string to com.mysql.jdbc.log.LogUtils so that third parties can use it. - DatabaseMetaData.supportsMultipleOpenResults() now returns true. The driver has supported this for some time, DBMD just missed that fact. - Fixed BUG#10310 - Driver doesn't support {?=CALL(...)} for calling stored functions. This involved adding support for function retrieval to DatabaseMetaData.getProcedures() and getProcedureColumns() as well. - Fixed BUG#10485, SQLException thrown when retrieving YEAR(2) with ResultSet.getString(). The driver will now always treat YEAR types as java.sql.Dates and return the correct values for getString(). Alternatively, the "yearIsDateType" connection property can be set to "false" and the values will be treated as SHORTs. - The datatype returned for TINYINT(1) columns when "tinyInt1isBit=true" (the default) can be switched between Types.BOOLEAN and Types.BIT using the new configuration property "transformedBitIsBoolean", which defaults to "false". If set to "false" (the default), DatabaseMetaData.getColumns() and ResultSetMetaData.getColumnType() will return Types.BOOLEAN for TINYINT(1) columns. If "true", Types.BOOLEAN will be returned instead. Irregardless of this configuration property, if "tinyInt1isBit" is enabled, columns with the type TINYINT(1) will be returned as java.lang.Boolean instances from ResultSet.getObject(..), and ResultSetMetaData.getColumnClassName() will return "java.lang.Boolean". - Fixed BUG#10496 - SQLException is thrown when using property "characterSetResults" with cp932 or eucjpms. - Reorganized directory layout, sources now in "src" folder, don't pollute parent directory when building, now output goes to "./build", distribution goes to "./dist". - Added support/bug hunting feature that generates .sql test scripts to STDERR when "autoGenerateTestcaseScript" is set to "true". - Fixed BUG#10850 - 0-length streams not sent to server when using server-side prepared statements. - Setting "cachePrepStmts=true" now causes the Connection to also cache the check the driver performs to determine if a prepared statement can be server-side or not, as well as caches server-side prepared statements for the lifetime of a connection. As before, the "prepStmtCacheSize" parameter controls the size of these caches. - Try to handle OutOfMemoryErrors more gracefully. Although not much can be done, they will in most cases close the connection they happened on so that further operations don't run into a connection in some unknown state. When an OOM has happened, any further operations on the connection will fail with a "Connection closed" exception that will also list the OOM exception as the reason for the implicit connection close event. - Don't send COM_RESET_STMT for each execution of a server-side prepared statement if it isn't required. - Driver detects if you're running MySQL-5.0.7 or later, and does not scan for "LIMIT ?[,?]" in statements being prepared, as the server supports those types of queries now. - Fixed BUG#11115, Varbinary data corrupted when using server-side prepared statements and ResultSet.getBytes(). - Connection.setCatalog() is now aware of the "useLocalSessionState" configuration property, which when set to true will prevent the driver from sending "USE ..." to the server if the requested catalog is the same as the current catalog. - Added the following configuration bundles, use one or many via the "useConfigs" configuration property: * maxPerformance -- maximum performance without being reckless * solarisMaxPerformance -- maximum performance for Solaris, avoids syscalls where it can * 3-0-Compat -- Compatibility with Connector/J 3.0.x functionality - Added "maintainTimeStats" configuration property (defaults to "true"), which tells the driver whether or not to keep track of the last query time and the last successful packet sent to the server's time. If set to false, removes two syscalls per query. - Fixed BUG#11259, autoReconnect ping causes exception on connection startup. - Fixed BUG#11360 Connector/J dumping query into SQLException twice - Fixed PreparedStatement.setClob() not accepting null as a parameter. - Fixed BUG#11411 - Production package doesn't include JBoss integration classes. - Removed nonsensical "costly type conversion" warnings when using usage advisor. 04-14-05 - Version 3.1.8-stable - Fixed DatabaseMetaData.getTables() returning views when they were not asked for as one of the requested table types. - Added support for new precision-math DECIMAL type in MySQL >= 5.0.3. - Fixed ResultSet.getTime() on a NULL value for server-side prepared statements throws NPE. - Made Connection.ping() a public method. - Fixed Bug#8868, DATE_FORMAT() queries returned as BLOBs from getObject(). - ServerPreparedStatements now correctly 'stream' BLOB/CLOB data to the server. You can configure the threshold chunk size using the JDBC URL property 'blobSendChunkSize' (the default is one megabyte). - BlobFromLocator now uses correct identifier quoting when generating prepared statements. - Server-side session variables can be preset at connection time by passing them as a comma-delimited list for the connection property 'sessionVariables'. - Fixed regression in ping() for users using autoReconnect=true. - Fixed BUG#9040 - PreparedStatement.addBatch() doesn't work with server-side prepared statements and streaming BINARY data. - Fixed BUG#8800 - DBMD.supportsMixedCase*Identifiers() returns wrong value on servers running on case-sensitive filesystems. - Fixed BUG#9206, can not use 'UTF-8' for characterSetResults configuration property. - Fixed BUG#9236, a continuation of BUG#8868, where functions used in queries that should return non-string types when resolved by temporary tables suddenly become opaque binary strings (work-around for server limitation). Also fixed fields with type of CHAR(n) CHARACTER SET BINARY to return correct/matching classes for RSMD.getColumnClassName() and ResultSet.getObject(). - Fixed BUG#8792 - DBMD.supportsResultSetConcurrency() not returning true for forward-only/read-only result sets (we obviously support this). - Fixed BUG#8803, 'DATA_TYPE' column from DBMD.getBestRowIdentifier() causes ArrayIndexOutOfBoundsException when accessed (and in fact, didn't return any value). - Check for empty strings ('') when converting char/varchar column data to numbers, throw exception if 'emptyStringsConvertToZero' configuration property is set to 'false' (for backwards-compatibility with 3.0, it is now set to 'true' by default, but will most likely default to 'false' in 3.2). - Fixed BUG#9320 - PreparedStatement.getMetaData() inserts blank row in database under certain conditions when not using server-side prepared statements. - Connection.canHandleAsPreparedStatement() now makes 'best effort' to distinguish LIMIT clauses with placeholders in them from ones without in order to have fewer false positives when generating work-arounds for statements the server cannot currently handle as server-side prepared statements. - Fixed build.xml to not compile log4j logging if log4j not available. - Added support for the c3p0 connection pool's (http://c3p0.sf.net/) validation/connection checker interface which uses the lightweight 'COM_PING' call to the server if available. To use it, configure your c3p0 connection pool's 'connectionTesterClassName' property to use 'com.mysql.jdbc.integration.c3p0.MysqlConnectionTester'. - Better detection of LIMIT inside/outside of quoted strings so that the driver can more correctly determine whether a prepared statement can be prepared on the server or not. - Fixed BUG#9319 - Stored procedures with same name in different databases confuse the driver when it tries to determine parameter counts/types. - Added finalizers to ResultSet and Statement implementations to be JDBC spec-compliant, which requires that if not explicitly closed, these resources should be closed upon garbage collection. - Fixed BUG#9682 - Stored procedures with DECIMAL parameters with storage specifications that contained "," in them would fail. - PreparedStatement.setObject(int, Object, int type, int scale) now uses scale value for BigDecimal instances. - Fixed BUG#9704 - Statement.getMoreResults() could throw NPE when existing result set was .close()d. - The performance metrics feature now gathers information about number of tables referenced in a SELECT. - The logging system is now automatically configured. If the value has been set by the user, via the URL property "logger" or the system property "com.mysql.jdbc.logger", then use that, otherwise, autodetect it using the following steps: Log4j, if it's available, Then JDK1.4 logging, Then fallback to our STDERR logging. - Fixed BUG#9778, DBMD.getTables() shouldn't return tables if views are asked for, even if the database version doesn't support views. - Fixed driver not returning 'true' for '-1' when ResultSet.getBoolean() was called on result sets returned from server-side prepared statements. - Added a Manifest.MF file with implementation information to the .jar file. - More tests in Field.isOpaqueBinary() to distinguish opaque binary (i.e. fields with type CHAR(n) and CHARACTER SET BINARY) from output of various scalar and aggregate functions that return strings. - Fixed BUG#9917 - Should accept null for catalog (meaning use current) in DBMD methods, even though it's not JDBC-compliant for legacy's sake. Disable by setting connection property "nullCatalogMeansCurrent" to "false" (which will be the default value in C/J 3.2.x). - Fixed BUG#9769 - Should accept null for name patterns in DBMD (meaning "%"), even though it isn't JDBC compliant, for legacy's sake. Disable by setting connection property "nullNamePatternMatchesAll" to "false" (which will be the default value in C/J 3.2.x). 02-18-05 - Version 3.1.7-stable - Fixed BUG#7686, Timestamp key column data needed "_binary'" stripped for UpdatableResultSet.refreshRow(). - Fixed BUG#7715 - Timestamps converted incorrectly to strings with Server-side prepared statements and updatable result sets. - Detect new sql_mode variable in string form (it used to be integer) and adjust quoting method for strings appropriately. - Added 'holdResultsOpenOverStatementClose' property (default is false), that keeps result sets open over statement.close() or new execution on same statement (suggested by Kevin Burton). - Fixed BUG#7952 -- Infinite recursion when 'falling back' to master in failover configuration. - Disable multi-statements (if enabled) for MySQL-4.1 versions prior to version 4.1.10 if the query cache is enabled, as the server returns wrong results in this configuration. - Fixed duplicated code in configureClientCharset() that prevented useOldUTF8Behavior=true from working properly. - Removed 'dontUnpackBinaryResults' functionality, the driver now always stores results from server-side prepared statements as-is from the server and unpacks them on demand. - Fixed BUG#8096 where emulated locators corrupt binary data when using server-side prepared statements. - Fixed synchronization issue with ServerPreparedStatement.serverPrepare() that could cause deadlocks/crashes if connection was shared between threads. - By default, the driver now scans SQL you are preparing via all variants of Connection.prepareStatement() to determine if it is a supported type of statement to prepare on the server side, and if it is not supported by the server, it instead prepares it as a client-side emulated prepared statement (BUG#4718). You can disable this by passing 'emulateUnsupportedPstmts=false' in your JDBC URL. - Remove _binary introducer from parameters used as in/out parameters in CallableStatement. - Always return byte[]s for output parameters registered as *BINARY. - Send correct value for 'boolean' "true" to server for PreparedStatement.setObject(n, "true", Types.BIT). - Fixed bug with Connection not caching statements from prepareStatement() when the statement wasn't a server-side prepared statement. - Choose correct 'direction' to apply time adjustments when both client and server are in GMT timezone when using ResultSet.get(..., cal) and PreparedStatement.set(...., cal). - Added 'dontTrackOpenResources' option (default is false, to be JDBC compliant), which helps with memory use for non-well-behaved apps (i.e applications which don't close Statements when they should). - Fixed BUG#8428 - ResultSet.getString() doesn't maintain format stored on server, bug fix only enabled when 'noDatetimeStringSync' property is set to 'true' (the default is 'false'). - Fixed NPE in ResultSet.realClose() when using usage advisor and result set was already closed. - Fixed BUG#8487 - PreparedStatements not creating streaming result sets. - Don't pass NULL to String.valueOf() in ResultSet.getNativeConvertToString(), as it stringifies it (i.e. returns "null"), which is not correct for the method in question. - Fixed BUG#8484 - ResultSet.getBigDecimal() throws exception when rounding would need to occur to set scale. The driver now chooses a rounding mode of 'half up' if non-rounding BigDecimal.setScale() fails. - Added 'useLocalSessionState' configuration property, when set to 'true' the JDBC driver trusts that the application is well-behaved and only sets autocommit and transaction isolation levels using the methods provided on java.sql.Connection, and therefore can manipulate these values in many cases without incurring round-trips to the database server. - Added enableStreamingResults() to Statement for connection pool implementations that check Statement.setFetchSize() for specification-compliant values. Call Statement.setFetchSize(>=0) to disable the streaming results for that statement. - Added support for BIT type in MySQL-5.0.3. The driver will treat BIT(1-8) as the JDBC standard BIT type (which maps to java.lang.Boolean), as the server does not currently send enough information to determine the size of a bitfield when < 9 bits are declared. BIT(>9) will be treated as VARBINARY, and will return byte[] when getObject() is called. 12-23-04 - Version 3.1.6-stable - Fixed hang on SocketInputStream.read() with Statement.setMaxRows() and multiple result sets when driver has to truncate result set directly, rather than tacking a 'LIMIT n' on the end of it. - Fixed BUG#7026 - DBMD.getProcedures() doesn't respect catalog parameter. 12-02-04 - Version 3.1.5-gamma - Fix comparisons made between string constants and dynamic strings that are either toUpperCase()d or toLowerCase()d to use Locale.ENGLISH, as some locales 'override' case rules for English. Also use StringUtils.indexOfIgnoreCase() instead of .toUpperCase().indexOf(), avoids creating a very short-lived transient String instance. - Fixed BUG#5235 - Server-side prepared statements did not honor 'zeroDateTimeBehavior' property, and would cause class-cast exceptions when using ResultSet.getObject(), as the all-zero string was always returned. - Fixed batched updates with server prepared statements weren't looking if the types had changed for a given batched set of parameters compared to the previous set, causing the server to return the error 'Wrong arguments to mysql_stmt_execute()'. - Handle case when string representation of timestamp contains trailing '.' with no numbers following it. - Fixed BUG#5706 - Inefficient detection of pre-existing string instances in ResultSet.getNativeString(). - Don't throw exceptions for Connection.releaseSavepoint(). - Use a per-session Calendar instance by default when decoding dates from ServerPreparedStatements (set to old, less performant behavior by setting property 'dynamicCalendars=true'). - Added experimental configuration property 'dontUnpackBinaryResults', which delays unpacking binary result set values until they're asked for, and only creates object instances for non-numerical values (it is set to 'false' by default). For some usecase/jvm combinations, this is friendlier on the garbage collector. - Fixed BUG#5729 - UNSIGNED BIGINT unpacked incorrectly from server-side prepared statement result sets. - Fixed BUG#6225 - ServerSidePreparedStatement allocating short-lived objects un-necessarily. - Removed un-wanted new Throwable() in ResultSet constructor due to bad merge (caused a new object instance that was never used for every result set created) - Found while profiling for BUG#6359. - Fixed too-early creation of StringBuffer in EscapeProcessor.escapeSQL(), also return String when escaping not needed (to avoid unnecssary object allocations). Found while profiling for BUG#6359. - Use null-safe-equals for key comparisons in updatable result sets. - Fixed BUG#6537, SUM() on Decimal with server-side prepared statement ignores scale if zero-padding is needed (this ends up being due to conversion to DOUBLE by server, which when converted to a string to parse into BigDecimal, loses all 'padding' zeros). - Use DatabaseMetaData.getIdentifierQuoteString() when building DBMD queries. - Use 1MB packet for sending file for LOAD DATA LOCAL INFILE if that is < 'max_allowed_packet' on server. - Fixed BUG#6399, ResultSetMetaData.getColumnDisplaySize() returns incorrect values for multi-byte charsets. - Make auto-deserialization of java.lang.Objects stored in BLOBs configurable via 'autoDeserialize' property (defaults to 'false'). - Re-work Field.isOpaqueBinary() to detect 'CHAR(n) CHARACTER SET BINARY' to support fixed-length binary fields for ResultSet.getObject(). - Use our own implementation of buffered input streams to get around blocking behavior of java.io.BufferedInputStream. Disable this with 'useReadAheadInput=false'. - Fixed BUG#6348, failing to connect to the server when one of the addresses for the given host name is IPV6 (which the server does not yet bind on). The driver now loops through _all_ IP addresses for a given host, and stops on the first one that accepts() a socket.connect(). 09-04-04 - Version 3.1.4-beta - Fixed BUG#4510 - connector/j 3.1.3 beta does not handle integers correctly (caused by changes to support unsigned reads in Buffer.readInt() -> Buffer.readShort()). - Added support in DatabaseMetaData.getTables() and getTableTypes() for VIEWs which are now available in MySQL server version 5.0.x. - Fixed BUG#4642 -- ServerPreparedStatement.execute*() sometimes threw ArrayIndexOutOfBoundsException when unpacking field metadata. - Optimized integer number parsing, enable 'old' slower integer parsing using JDK classes via 'useFastIntParsing=false' property. - Added 'useOnlyServerErrorMessages' property, which causes message text in exceptions generated by the server to only contain the text sent by the server (as opposed to the SQLState's 'standard' description, followed by the server's error message). This property is set to 'true' by default. - Fixed BUG#4689 - ResultSet.wasNull() does not work for primatives if a previous null was returned. - Track packet sequence numbers if enablePacketDebug=true, and throw an exception if packets received out-of-order. - Fixed BUG#4482, ResultSet.getObject() returns wrong type for strings when using prepared statements. - Calling MysqlPooledConnection.close() twice (even though an application error), caused NPE. Fixed. - Fixed BUG#5012 -- ServerPreparedStatements dealing with return of DECIMAL type don't work. - Fixed BUG#5032 -- ResultSet.getObject() doesn't return type Boolean for pseudo-bit types from prepared statements on 4.1.x (shortcut for avoiding extra type conversion when using binary-encoded result sets obscurred test in getObject() for 'pseudo' bit type) - You can now use URLs in 'LOAD DATA LOCAL INFILE' statements, and the driver will use Java's built-in handlers for retreiving the data and sending it to the server. This feature is not enabled by default, you must set the 'allowUrlInLocalInfile' connection property to 'true'. - The driver is more strict about truncation of numerics on ResultSet.get*(), and will throw a SQLException when truncation is detected. You can disable this by setting 'jdbcCompliantTruncation' to false (it is enabled by default, as this functionality is required for JDBC compliance). - Added three ways to deal with all-zero datetimes when reading them from a ResultSet, 'exception' (the default), which throws a SQLException with a SQLState of 'S1009', 'convertToNull', which returns NULL instead of the date, and 'round', which rounds the date to the nearest closest value which is '0001-01-01'. - Fixed ServerPreparedStatement to read prepared statement metadata off the wire, even though it's currently a placeholder instead of using MysqlIO.clearInputStream() which didn't work at various times because data wasn't available to read from the server yet. This fixes sporadic errors users were having with ServerPreparedStatements throwing ArrayIndexOutOfBoundExceptions. - Use com.mysql.jdbc.Message's classloader when loading resource bundle, should fix sporadic issues when the caller's classloader can't locate the resource bundle. 07-07-04 - Version 3.1.3-beta - Mangle output parameter names for CallableStatements so they will not clash with user variable names. - Added support for INOUT parameters in CallableStatements. - Fix for BUG#4119, null bitmask sent for server-side prepared statements was incorrect. - Use SQL Standard SQL states by default, unless 'useSqlStateCodes' property is set to 'false'. - Added packet debuging code (see the 'enablePacketDebug' property documentation). - Added constants for MySQL error numbers (publicly-accessible, see com.mysql.jdbc.MysqlErrorNumbers), and the ability to generate the mappings of vendor error codes to SQLStates that the driver uses (for documentation purposes). - Externalized more messages (on-going effort). - Fix for BUG#4311 - Error in retrieval of mediumint column with prepared statements and binary protocol. - Support new timezone variables in MySQL-4.1.3 when 'useTimezone=true' - Support for unsigned numerics as return types from prepared statements. This also causes a change in ResultSet.getObject() for the 'bigint unsigned' type, which used to return BigDecimal instances, it now returns instances of java.lang.BigInteger. 06-09-04 - Version 3.1.2-alpha - Fixed stored procedure parameter parsing info when size was specified for a parameter (i.e. char(), varchar()). - Enabled callable statement caching via 'cacheCallableStmts' property. - Fixed case when no output parameters specified for a stored procedure caused a bogus query to be issued to retrieve out parameters, leading to a syntax error from the server. - Fixed case when no parameters could cause a NullPointerException in CallableStatement.setOutputParameters(). - Removed wrapping of exceptions in MysqlIO.changeUser(). - Fixed sending of split packets for large queries, enabled nio ability to send large packets as well. - Added .toString() functionality to ServerPreparedStatement, which should help if you're trying to debug a query that is a prepared statement (it shows SQL as the server would process). - Added 'gatherPerformanceMetrics' property, along with properties to control when/where this info gets logged (see docs for more info). - ServerPreparedStatements weren't actually de-allocating server-side resources when .close() was called. - Added 'logSlowQueries' property, along with property 'slowQueriesThresholdMillis' to control when a query should be considered 'slow'. - Correctly map output parameters to position given in prepareCall() vs. order implied during registerOutParameter() - fixes BUG#3146. - Correctly detect initial character set for servers >= 4.1.0 - Cleaned up detection of server properties. - Support placeholder for parameter metadata for server >= 4.1.2 - Fix for BUG#3539 getProcedures() does not return any procedures in result set - Fix for BUG#3540 getProcedureColumns() doesn't work with wildcards for procedure name - Fixed BUG#3520 -- DBMD.getSQLStateType() returns incorrect value. - Added 'connectionCollation' property to cause driver to issue 'set collation_connection=...' query on connection init if default collation for given charset is not appropriate. - Fixed DatabaseMetaData.getProcedures() when run on MySQL-5.0.0 (output of 'show procedure status' changed between 5.0.1 and 5.0.0. - Fixed BUG#3804 -- getWarnings() returns SQLWarning instead of DataTruncation - Don't enable server-side prepared statements for server version 5.0.0 or 5.0.1, as they aren't compatible with the '4.1.2+' style that the driver uses (the driver expects information to come back that isn't there, so it hangs). 02-14-04 - Version 3.1.1-alpha - Fixed bug with UpdatableResultSets not using client-side prepared statements. - Fixed character encoding issues when converting bytes to ASCII when MySQL doesn't provide the character set, and the JVM is set to a multi-byte encoding (usually affecting retrieval of numeric values). - Unpack 'unknown' data types from server prepared statements as Strings. - Implemented long data (Blobs, Clobs, InputStreams, Readers) for server prepared statements. - Implemented Statement.getWarnings() for MySQL-4.1 and newer (using 'SHOW WARNINGS'). - Default result set type changed to TYPE_FORWARD_ONLY (JDBC compliance). - Centralized setting of result set type and concurrency. - Re-factored how connection properties are set and exposed as DriverPropertyInfo as well as Connection and DataSource properties. - Support for NIO. Use 'useNIO=true' on platforms that support NIO. - Support for SAVEPOINTs (MySQL >= 4.0.14 or 4.1.1). - Support for mysql_change_user()...See the changeUser() method in com.mysql.jdbc.Connection. - Reduced number of methods called in average query to be more efficient. - Prepared Statements will be re-prepared on auto-reconnect. Any errors encountered are postponed until first attempt to re-execute the re-prepared statement. - Ensure that warnings are cleared before executing queries on prepared statements, as-per JDBC spec (now that we support warnings). - Support 'old' profileSql capitalization in ConnectionProperties. This property is deprecated, you should use 'profileSQL' if possible. - Optimized Buffer.readLenByteArray() to return shared empty byte array when length is 0. - Allow contents of PreparedStatement.setBlob() to be retained between calls to .execute*(). - Deal with 0-length tokens in EscapeProcessor (caused by callable statement escape syntax). - Check for closed connection on delete/update/insert row operations in UpdatableResultSet. - Fix support for table aliases when checking for all primary keys in UpdatableResultSet. - Removed useFastDates connection property. - Correctly initialize datasource properties from JNDI Refs, including explicitly specified URLs. - DatabaseMetaData now reports supportsStoredProcedures() for MySQL versions >= 5.0.0 - Fixed stack overflow in Connection.prepareCall() (bad merge). - Fixed IllegalAccessError to Calendar.getTimeInMillis() in DateTimeValue (for JDK < 1.4). - Fix for BUG#1673, where DatabaseMetaData.getColumns() is not returning correct column ordinal info for non '%' column name patterns. - Merged fix of datatype mapping from MySQL type 'FLOAT' to java.sql.Types.REAL from 3.0 branch. - Detect collation of column for RSMD.isCaseSensitive(). - Fixed sending of queries > 16M. - Added named and indexed input/output parameter support to CallableStatement. MySQL-5.0.x or newer. - Fixed NullPointerException in ServerPreparedStatement.setTimestamp(), as well as year and month descrepencies in ServerPreparedStatement.setTimestamp(), setDate(). - Added ability to have multiple database/JVM targets for compliance and regression/unit tests in build.xml. - Fixed NPE and year/month bad conversions when accessing some datetime functionality in ServerPreparedStatements and their resultant result sets. - Display where/why a connection was implicitly closed (to aid debugging). - CommunicationsException implemented, that tries to determine why communications was lost with a server, and displays possible reasons when .getMessage() is called. - Fixed BUG#2359, NULL values for numeric types in binary encoded result sets causing NullPointerExceptions. - Implemented Connection.prepareCall(), and DatabaseMetaData. getProcedures() and getProcedureColumns(). - Reset 'long binary' parameters in ServerPreparedStatement when clearParameters() is called, by sending COM_RESET_STMT to the server. - Merged prepared statement caching, and .getMetaData() support from 3.0 branch. - Fixed off-by-1900 error in some cases for years in TimeUtil.fastDate/TimeCreate() when unpacking results from server-side prepared statements. - Fixed BUG#2502 -- charset conversion issue in getTables(). - Implemented multiple result sets returned from a statement or stored procedure. - Fixed BUG#2606 -- Server side prepared statements not returning datatype 'YEAR' correctly. - Enabled streaming of result sets from server-side prepared statements. - Fixed BUG#2623 -- Class-cast exception when using scrolling result sets and server-side prepared statements. - Merged unbuffered input code from 3.0. - Fixed ConnectionProperties that weren't properly exposed via accessors, cleaned up ConnectionProperties code. - Fixed BUG#2671, NULL fields not being encoded correctly in all cases in server side prepared statements. - Fixed rare buffer underflow when writing numbers into buffers for sending prepared statement execution requests. - Use DocBook version of docs for shipped versions of drivers. 02-18-03 - Version 3.1.0-alpha - Added 'requireSSL' property. - Added 'useServerPrepStmts' property (default 'false'). The driver will use server-side prepared statements when the server version supports them (4.1 and newer) when this property is set to 'true'. It is currently set to 'false' by default until all bind/fetch functionality has been implemented. Currently only DML prepared statements are implemented for 4.1 server-side prepared statements. - Track open Statements, close all when Connection.close() is called (JDBC compliance). 06-23-05 - Version 3.0.17-ga - Fixed BUG#5874, Timestamp/Time conversion goes in the wrong 'direction' when useTimeZone='true' and server timezone differs from client timezone. - Fixed BUG#7081, DatabaseMetaData.getIndexInfo() ignoring 'unique' parameter. - Support new protocol type 'MYSQL_TYPE_VARCHAR'. - Added 'useOldUTF8Behavoior' configuration property, which causes JDBC driver to act like it did with MySQL-4.0.x and earlier when the character encoding is 'utf-8' when connected to MySQL-4.1 or newer. - Fixed BUG#7316 - Statements created from a pooled connection were returning physical connection instead of logical connection when getConnection() was called. - Fixed BUG#7033 - PreparedStatements don't encode Big5 (and other multi-byte) character sets correctly in static SQL strings. - Fixed BUG#6966, connections starting up failed-over (due to down master) never retry master. - Fixed BUG#7061, PreparedStatement.fixDecimalExponent() adding extra '+', making number unparseable by MySQL server. - Fixed BUG#7686, Timestamp key column data needed "_binary'" stripped for UpdatableResultSet.refreshRow(). - Backported SQLState codes mapping from Connector/J 3.1, enable with 'useSqlStateCodes=true' as a connection property, it defaults to 'false' in this release, so that we don't break legacy applications (it defaults to 'true' starting with Connector/J 3.1). - Fixed BUG#7601, PreparedStatement.fixDecimalExponent() adding extra '+', making number unparseable by MySQL server. - Escape sequence {fn convert(..., type)} now supports ODBC-style types that are prepended by 'SQL_'. - Fixed duplicated code in configureClientCharset() that prevented useOldUTF8Behavior=true from working properly. - Handle streaming result sets with > 2 billion rows properly by fixing wraparound of row number counter. - Fixed BUG#7607 - MS932, SHIFT_JIS and Windows_31J not recog. as aliases for sjis. - Fixed BUG#6549 (while fixing #7607), adding 'CP943' to aliases for sjis. - Fixed BUG#8064, which requires hex escaping of binary data when using multi-byte charsets with prepared statements. - Fixed BUG#8812, NON_UNIQUE column from DBMD.getIndexInfo() returned inverted value. - Workaround for server BUG#9098 - default values of CURRENT_* for DATE/TIME/TIMESTAMP/TIMESTAMP columns can't be distinguished from 'string' values, so UpdatableResultSet.moveToInsertRow() generates bad SQL for inserting default values. - Fixed BUG#8629 - 'EUCKR' charset is sent as 'SET NAMES euc_kr' which MySQL-4.1 and newer doesn't understand. - DatabaseMetaData.supportsSelectForUpdate() returns correct value based on server version. - Use hex escapes for PreparedStatement.setBytes() for double-byte charsets including 'aliases' Windows-31J, CP934, MS932. - Added support for the "EUC_JP_Solaris" character encoding, which maps to a MySQL encoding of "eucjpms" (backported from 3.1 branch). This only works on servers that support eucjpms, namely 5.0.3 or later. 11-15-04 - Version 3.0.16-ga - Re-issue character set configuration commands when re-using pooled connections and/or Connection.changeUser() when connected to MySQL-4.1 or newer. - Fixed ResultSetMetaData.isReadOnly() to detect non-writable columns when connected to MySQL-4.1 or newer, based on existence of 'original' table and column names. - Fixed BUG#5664, ResultSet.updateByte() when on insert row throws ArrayOutOfBoundsException. - Fixed DatabaseMetaData.getTypes() returning incorrect (i.e. non-negative) scale for the 'NUMERIC' type. - Fixed BUG#6198, off-by-one bug in Buffer.readString(string). - Made TINYINT(1) -> BIT/Boolean conversion configurable via 'tinyInt1isBit' property (default 'true' to be JDBC compliant out of the box). - Only set 'character_set_results' during connection establishment if server version >= 4.1.1. - Fixed regression where useUnbufferedInput was defaulting to 'false'. - Fixed BUG#6231, ResultSet.getTimestamp() on a column with TIME in it fails. 09-04-04 - Version 3.0.15-production - Fixed BUG#4010 - StringUtils.escapeEasternUnicodeByteStream is still broken for GBK - Fixed BUG#4334 - Failover for autoReconnect not using port #'s for any hosts, and not retrying all hosts. (WARN: This required a change to the SocketFactory connect() method signature, which is now public Socket connect(String host, int portNumber, Properties props) therefore any third-party socket factories will have to be changed to support this signature. - Logical connections created by MysqlConnectionPoolDataSource will now issue a rollback() when they are closed and sent back to the pool. If your application server/connection pool already does this for you, you can set the 'rollbackOnPooledClose' property to false to avoid the overhead of an extra rollback(). - Removed redundant calls to checkRowPos() in ResultSet. - Fixed BUG#4742, 'DOUBLE' mapped twice in DBMD.getTypeInfo(). - Added FLOSS license exemption. - Fixed BUG#4808, calling .close() twice on a PooledConnection causes NPE. - Fixed BUG#4138 and BUG#4860, DBMD.getColumns() returns incorrect JDBC type for unsigned columns. This affects type mappings for all numeric types in the RSMD.getColumnType() and RSMD.getColumnTypeNames() methods as well, to ensure that 'like' types from DBMD.getColumns() match up with what RSMD.getColumnType() and getColumnTypeNames() return. - 'Production' - 'GA' in naming scheme of distributions. - Fix for BUG#4880, RSMD.getPrecision() returning 0 for non-numeric types (should return max length in chars for non-binary types, max length in bytes for binary types). This fix also fixes mapping of RSMD.getColumnType() and RSMD.getColumnTypeName() for the BLOB types based on the length sent from the server (the server doesn't distinguish between TINYBLOB, BLOB, MEDIUMBLOB or LONGBLOB at the network protocol level). - Fixed BUG#5022 - ResultSet should release Field[] instance in .close(). - Fixed BUG#5069 -- ResultSet.getMetaData() should not return incorrectly-initialized metadata if the result set has been closed, but should instead throw a SQLException. Also fixed for getRow() and getWarnings() and traversal methods by calling checkClosed() before operating on instance-level fields that are nullified during .close(). - Parse new timezone variables from 4.1.x servers. - Use _binary introducer for PreparedStatement.setBytes() and set*Stream() when connected to MySQL-4.1.x or newer to avoid misinterpretation during character conversion. 05-28-04 - Version 3.0.14-production - Fixed URL parsing error 05-27-04 - Version 3.0.13-production - Fixed BUG#3848 - Using a MySQLDatasource without server name fails - Fixed BUG#3920 - "No Database Selected" when using MysqlConnectionPoolDataSource. - Fixed BUG#3873 - PreparedStatement.getGeneratedKeys() method returns only 1 result for batched insertions 05-18-04 - Version 3.0.12-production - Add unsigned attribute to DatabaseMetaData.getColumns() output in the TYPE_NAME column. - Added 'failOverReadOnly' property, to allow end-user to configure state of connection (read-only/writable) when failed over. - Backported 'change user' and 'reset server state' functionality from 3.1 branch, to allow clients of MysqlConnectionPoolDataSource to reset server state on getConnection() on a pooled connection. - Don't escape SJIS/GBK/BIG5 when using MySQL-4.1 or newer. - Allow 'url' parameter for MysqlDataSource and MysqlConnectionPool DataSource so that passing of other properties is possible from inside appservers. - Map duplicate key and foreign key errors to SQLState of '23000'. - Backport documentation tooling from 3.1 branch. - Return creating statement for ResultSets created by getGeneratedKeys() (BUG#2957) - Allow java.util.Date to be sent in as parameter to PreparedStatement.setObject(), converting it to a Timestamp to maintain full precision (BUG#3103). - Don't truncate BLOBs/CLOBs when using setBytes() and/or setBinary/CharacterStream() (BUG#2670). - Dynamically configure character set mappings for field-level character sets on MySQL-4.1.0 and newer using 'SHOW COLLATION' when connecting. - Map 'binary' character set to 'US-ASCII' to support DATETIME charset recognition for servers >= 4.1.2 - Use 'SET character_set_results" during initialization to allow any charset to be returned to the driver for result sets. - Use charsetnr returned during connect to encode queries before issuing 'SET NAMES' on MySQL >= 4.1.0. - Add helper methods to ResultSetMetaData (getColumnCharacterEncoding() and getColumnCharacterSet()) to allow end-users to see what charset the driver thinks it should be using for the column. - Only set character_set_results for MySQL >= 4.1.0. - Fixed BUG#3511, StringUtils.escapeSJISByteStream() not covering all eastern double-byte charsets correctly. - Renamed StringUtils.escapeSJISByteStream() to more appropriate escapeEasternUnicodeByteStream(). - Fixed BUG#3554 - Not specifying database in URL caused MalformedURL exception. - Auto-convert MySQL encoding names to Java encoding names if used for characterEncoding property. - Added encoding names that are recognized on some JVMs to fix case where they were reverse-mapped to MySQL encoding names incorrectly. - Use junit.textui.TestRunner for all unit tests (to allow them to be run from the command line outside of Ant or Eclipse). - Fixed BUG#3557 - UpdatableResultSet not picking up default values for moveToInsertRow(). - Fixed BUG#3570 - inconsistent reporting of column type. The server still doesn't return all types for *BLOBs *TEXT correctly, so the driver won't return those correctly. - Fixed BUG#3520 -- DBMD.getSQLStateType() returns incorrect value. - Fixed regression in PreparedStatement.setString() and eastern character encodings. - Made StringRegressionTest 4.1-unicode aware. 02-19-04 - Version 3.0.11-stable - Trigger a 'SET NAMES utf8' when encoding is forced to 'utf8' _or_ 'utf-8' via the 'characterEncoding' property. Previously, only the Java-style encoding name of 'utf-8' would trigger this. - AutoReconnect time was growing faster than exponentially (BUG#2447). - Fixed failover always going to last host in list (BUG#2578) - Added 'useUnbufferedInput' parameter, and now use it by default (due to JVM issue http://developer.java.sun.com/developer/bugParade/bugs/4401235.html) - Detect 'on/off' or '1','2','3' form of lower_case_table_names on server. - Return 'java.lang.Integer' for TINYINT and SMALLINT types from ResultSetMetaData.getColumnClassName() (fix for BUG#2852). - Return 'java.lang.Double' for FLOAT type from ResultSetMetaData. getColumnClassName() (fix for BUG#2855). - Return '[B' instead of java.lang.Object for BINARY, VARBINARY and LONGVARBINARY types from ResultSetMetaData.getColumnClassName() (JDBC compliance). - Issue connection events on all instances created from a ConnectionPoolDataSource. 01-13-04 - Version 3.0.10-stable - Don't count quoted id's when inside a 'string' in PreparedStatement parsing (fix for BUG#1511). - 'Friendlier' exception message for PacketTooLargeException (BUG#1534). - Backported fix for aliased tables and UpdatableResultSets in checkUpdatability() method from 3.1 branch. - Fix for ArrayIndexOutOfBounds exception when using Statement.setMaxRows() (BUG#1695). - Fixed BUG#1576, dealing with large blobs and split packets not being read correctly. - Fixed regression of Statement.getGeneratedKeys() and REPLACE statements. - Fixed BUG#1630, subsequent call to ResultSet.updateFoo() causes NPE if result set is not updatable. - Fix for 4.1.1-style auth with no password. - Fix for BUG#1731, Foreign Keys column sequence is not consistent in DatabaseMetaData.getImported/Exported/CrossReference(). - Fix for BUG#1775 - DatabaseMetaData.getSystemFunction() returning bad function 'VResultsSion'. - Fix for BUG#1592 -- cross-database updatable result sets are not checked for updatability correctly. - DatabaseMetaData.getColumns() should return Types.LONGVARCHAR for MySQL LONGTEXT type. - ResultSet.getObject() on TINYINT and SMALLINT columns should return Java type 'Integer' (BUG#1913) - Added 'alwaysClearStream' connection property, which causes the driver to always empty any remaining data on the input stream before each query. - Added more descriptive error message 'Server Configuration Denies Access to DataSource', as well as retrieval of message from server. - Autoreconnect code didn't set catalog upon reconnect if it had been changed. - Implement ResultSet.updateClob(). - ResultSetMetaData.isCaseSensitive() returned wrong value for CHAR/VARCHAR columns. - Fix for BUG#1933 -- Connection property "maxRows" not honored. - Fix for BUG#1925 -- Statements being created too many times in DBMD.extractForeignKeyFromCreateTable(). - Fix for BUG#1914 -- Support escape sequence {fn convert ... } - Fix for BUG#1958 -- ArrayIndexOutOfBounds when parameter number == number of parameters + 1. - Fix for BUG#2006 -- ResultSet.findColumn() should use first matching column name when there are duplicate column names in SELECT query (JDBC-compliance). - Removed static synchronization bottleneck from PreparedStatement.setTimestamp(). - Removed static synchronization bottleneck from instance factory method of SingleByteCharsetConverter. - Enable caching of the parsing stage of prepared statements via the 'cachePrepStmts', 'prepStmtCacheSize' and 'prepStmtCacheSqlLimit' properties (disabled by default). - Speed up parsing of PreparedStatements, try to use one-pass whenever possible. - Fixed security exception when used in Applets (applets can't read the system property 'file.encoding' which is needed for LOAD DATA LOCAL INFILE). - Use constants for SQLStates. - Map charset 'ko18_ru' to 'ko18r' when connected to MySQL-4.1.0 or newer. - Ensure that Buffer.writeString() saves room for the \0. - Fixed exception 'Unknown character set 'danish' on connect w/ JDK-1.4.0 - Fixed mappings in SQLError to report deadlocks with SQLStates of '41000'. - 'maxRows' property would affect internal statements, so check it for all statement creation internal to the driver, and set to 0 when it is not. 10-07-03 - Version 3.0.9-stable - Faster date handling code in ResultSet and PreparedStatement (no longer uses Date methods that synchronize on static calendars). - Fixed test for end of buffer in Buffer.readString(). - Fixed ResultSet.previous() behavior to move current position to before result set when on first row of result set (bugs.mysql.com BUG#496) - Fixed Statement and PreparedStatement issuing bogus queries when setMaxRows() had been used and a LIMIT clause was present in the query. - Fixed BUG#661 - refreshRow didn't work when primary key values contained values that needed to be escaped (they ended up being doubly-escaped). - Support InnoDB contraint names when extracting foreign key info in DatabaseMetaData BUG#517 and BUG#664 (impl. ideas from Parwinder Sekhon) - Backported 4.1 protocol changes from 3.1 branch (server-side SQL states, new field info, larger client capability flags, connect-with-database, etc). - Fix UpdatableResultSet to return values for getXXX() when on insert row (BUG#675). - The insertRow in an UpdatableResultSet is now loaded with the default column values when moveToInsertRow() is called (BUG#688) - DatabaseMetaData.getColumns() wasn't returning NULL for default values that are specified as NULL. - Change default statement type/concurrency to TYPE_FORWARD_ONLY and CONCUR_READ_ONLY (spec compliance). - Don't try and reset isolation level on reconnect if MySQL doesn't support them. - Don't wrap SQLExceptions in RowDataDynamic. - Don't change timestamp TZ twice if useTimezone==true (BUG#774) - Fixed regression in large split-packet handling (BUG#848). - Better diagnostic error messages in exceptions for 'streaming' result sets. - Issue exception on ResultSet.getXXX() on empty result set (wasn't caught in some cases). - Don't hide messages from exceptions thrown in I/O layers. - Don't fire connection closed events when closing pooled connections, or on PooledConnection.getConnection() with already open connections (BUG#884). - Clip +/- INF (to smallest and largest representative values for the type in MySQL) and NaN (to 0) for setDouble/setFloat(), and issue a warning on the statement when the server does not support +/- INF or NaN. - Fix for BUG#879, double-escaping of '\' when charset is SJIS or GBK and '\' appears in non-escaped input. - When emptying input stream of unused rows for 'streaming' result sets, have the current thread yield() every 100 rows in order to not monopolize CPU time. - Fixed BUG#1099, DatabaseMetaData.getColumns() getting confused about the keyword 'set' in character columns. - Fixed deadlock issue with Statement.setMaxRows(). - Fixed CLOB.truncate(), BUG#1130 - Optimized CLOB.setChracterStream(), BUG#1131 - Made databaseName, portNumber and serverName optional parameters for MysqlDataSourceFactory (BUG#1246) - Fix for BUG#1247 -- ResultSet.get/setString mashing char 127 - Backported auth. changes for 4.1.1 and newer from 3.1 branch. - Added com.mysql.jdbc.util.BaseBugReport to help creation of testcases for bug reports. - Added property to 'clobber' streaming results, by setting the 'clobberStreamingResults' property to 'true' (the default is 'false'). This will cause a 'streaming' ResultSet to be automatically closed, and any oustanding data still streaming from the server to be discarded if another query is executed before all the data has been read from the server. 05-23-03 - Version 3.0.8-stable - Allow bogus URLs in Driver.getPropertyInfo(). - Return list of generated keys when using multi-value INSERTS with Statement.getGeneratedKeys(). - Use JVM charset with filenames and 'LOAD DATA [LOCAL] INFILE' - Fix infinite loop with Connection.cleanup(). - Changed Ant target 'compile-core' to 'compile-driver', and made testsuite compilation a separate target. - Fixed result set not getting set for Statement.executeUpdate(), which affected getGeneratedKeys() and getUpdateCount() in some cases. - Unicode character 0xFFFF in a string would cause the driver to throw an ArrayOutOfBoundsException (Bug #378) - Return correct amount of generated keys when using 'REPLACE' statements. - Fix problem detecting server character set in some cases. - Fix row data decoding error when using _very_ large packets. - Optimized row data decoding. - Issue exception when operating on an already-closed prepared statement. - Fixed SJIS encoding bug, thanks to Naoto Sato. - Optimized usage of EscapeProcessor. - Allow multiple calls to Statement.close() 04-08-03 - Version 3.0.7-stable - Fixed MysqlPooledConnection.close() calling wrong event type. - Fixed StringIndexOutOfBoundsException in PreparedStatement. setClob(). - 4.1 Column Metadata fixes - Remove synchronization from Driver.connect() and Driver.acceptsUrl(). - IOExceptions during a transaction now cause the Connection to be closed. - Fixed missing conversion for 'YEAR' type in ResultSetMetaData. getColumnTypeName(). - Don't pick up indexes that start with 'pri' as primary keys for DBMD.getPrimaryKeys(). - Throw SQLExceptions when trying to do operations on a forcefully closed Connection (i.e. when a communication link failure occurs). - You can now toggle profiling on/off using Connection.setProfileSql(boolean). - Fixed charset issues with database metadata (charset was not getting set correctly). - Updatable ResultSets can now be created for aliased tables/columns when connected to MySQL-4.1 or newer. - Fixed 'LOAD DATA LOCAL INFILE' bug when file > max_allowed_packet. - Fixed escaping of 0x5c ('\') character for GBK and Big5 charsets. - Fixed ResultSet.getTimestamp() when underlying field is of type DATE. - Ensure that packet size from alignPacketSize() does not exceed MAX_ALLOWED_PACKET (JVM bug) - Don't reset Connection.isReadOnly() when autoReconnecting. 02-18-03 - Version 3.0.6-stable - Fixed ResultSetMetaData to return "" when catalog not known. Fixes NullPointerExceptions with Sun's CachedRowSet. - Fixed DBMD.getTypeInfo() and DBMD.getColumns() returning different value for precision in TEXT/BLOB types. - Allow ignoring of warning for 'non transactional tables' during rollback (compliance/usability) by setting 'ignoreNonTxTables' property to 'true'. - Fixed SQLExceptions getting swallowed on initial connect. - Fixed Statement.setMaxRows() to stop sending 'LIMIT' type queries when not needed (performance) - Clean up Statement query/method mismatch tests (i.e. INSERT not allowed with .executeQuery()). - More checks added in ResultSet traversal method to catch when in closed state. - Fixed ResultSetMetaData.isWritable() to return correct value. - Add 'window' of different NULL sorting behavior to DBMD.nullsAreSortedAtStart (4.0.2 to 4.0.10, true, otherwise, no). - Implemented Blob.setBytes(). You still need to pass the resultant Blob back into an updatable ResultSet or PreparedStatement to persist the changes, as MySQL does not support 'locators'. - Backported 4.1 charset field info changes from Connector/J 3.1 01-22-03 - Version 3.0.5-gamma - Fixed Buffer.fastSkipLenString() causing ArrayIndexOutOfBounds exceptions with some queries when unpacking fields. - Implemented an empty TypeMap for Connection.getTypeMap() so that some third-party apps work with MySQL (IBM WebSphere 5.0 Connection pool). - Added missing LONGTEXT type to DBMD.getColumns(). - Retrieve TX_ISOLATION from database for Connection.getTransactionIsolation() when the MySQL version supports it, instead of an instance variable. - Quote table names in DatabaseMetaData.getColumns(), getPrimaryKeys(), getIndexInfo(), getBestRowIdentifier() - Greatly reduce memory required for setBinaryStream() in PreparedStatements. - Fixed ResultSet.isBeforeFirst() for empty result sets. - Added update options for foreign key metadata. 01-06-03 - Version 3.0.4-gamma - Added quoted identifiers to database names for Connection.setCatalog. - Added support for quoted identifiers in PreparedStatement parser. - Streamlined character conversion and byte[] handling in PreparedStatements for setByte(). - Reduce memory footprint of PreparedStatements by sharing outbound packet with MysqlIO. - Added 'strictUpdates' property to allow control of amount of checking for 'correctness' of updatable result sets. Set this to 'false' if you want faster updatable result sets and you know that you create them from SELECTs on tables with primary keys and that you have selected all primary keys in your query. - Added support for 4.0.8-style large packets. - Fixed PreparedStatement.executeBatch() parameter overwriting. 12-17-02 - Version 3.0.3-dev - Changed charsToByte in SingleByteCharConverter to be non-static - Changed SingleByteCharConverter to use lazy initialization of each converter. - Fixed charset handling in Fields.java - Implemented Connection.nativeSQL() - More robust escape tokenizer -- recognize '--' comments, and allow nested escape sequences (see testsuite.EscapeProcessingTest) - DBMD.getImported/ExportedKeys() now handles multiple foreign keys per table. - Fixed ResultSetMetaData.getPrecision() returning incorrect values for some floating point types. - Fixed ResultSetMetaData.getColumnTypeName() returning BLOB for TEXT and TEXT for BLOB types. - Fixed Buffer.isLastDataPacket() for 4.1 and newer servers. - Added CLIENT_LONG_FLAG to be able to get more column flags (isAutoIncrement() being the most important) - Because of above, implemented ResultSetMetaData.isAutoIncrement() to use Field.isAutoIncrement(). - Honor 'lower_case_table_names' when enabled in the server when doing table name comparisons in DatabaseMetaData methods. - Some MySQL-4.1 protocol support (extended field info from selects) - Use non-aliased table/column names and database names to fullly qualify tables and columns in UpdatableResultSet (requires MySQL-4.1 or newer) - Allow user to alter behavior of Statement/ PreparedStatement.executeBatch() via 'continueBatchOnError' property (defaults to 'true'). - Check for connection closed in more Connection methods (createStatement, prepareStatement, setTransactionIsolation, setAutoCommit). - More robust implementation of updatable result sets. Checks that _all_ primary keys of the table have been selected. - 'LOAD DATA LOCAL INFILE ...' now works, if your server is configured to allow it. Can be turned off with the 'allowLoadLocalInfile' property (see the README). - Substitute '?' for unknown character conversions in single-byte character sets instead of '\0'. - NamedPipeSocketFactory now works (only intended for Windows), see README for instructions. 11-08-02 - Version 3.0.2-dev - Fixed issue with updatable result sets and PreparedStatements not working - Fixed ResultSet.setFetchDirection(FETCH_UNKNOWN) - Fixed issue when calling Statement.setFetchSize() when using arbitrary values - Fixed incorrect conversion in ResultSet.getLong() - Implemented ResultSet.updateBlob(). - Removed duplicate code from UpdatableResultSet (it can be inherited from ResultSet, the extra code for each method to handle updatability I thought might someday be necessary has not been needed). - Fixed "UnsupportedEncodingException" thrown when "forcing" a character encoding via properties. - Fixed various non-ASCII character encoding issues. - Added driver property 'useHostsInPrivileges'. Defaults to true. Affects whether or not '@hostname' will be used in DBMD.getColumn/TablePrivileges. - All DBMD result set columns describing schemas now return NULL to be more compliant with the behavior of other JDBC drivers for other databases (MySQL does not support schemas). - Added SSL support. See README for information on how to use it. - Properly restore connection properties when autoReconnecting or failing-over, including autoCommit state, and isolation level. - Use 'SHOW CREATE TABLE' when possible for determining foreign key information for DatabaseMetaData...also allows cascade options for DELETE information to be returned - Escape 0x5c character in strings for the SJIS charset. - Fixed start position off-by-1 error in Clob.getSubString() - Implemented Clob.truncate() - Implemented Clob.setString() - Implemented Clob.setAsciiStream() - Implemented Clob.setCharacterStream() - Added com.mysql.jdbc.MiniAdmin class, which allows you to send 'shutdown' command to MySQL server...Intended to be used when 'embedding' Java and MySQL server together in an end-user application. - Added 'connectTimeout' parameter that allows users of JDK-1.4 and newer to specify a maxium time to wait to establish a connection. - Failover and autoReconnect only work when the connection is in a autoCommit(false) state, in order to stay transaction safe - Added 'queriesBeforeRetryMaster' property that specifies how many queries to issue when failed over before attempting to reconnect to the master (defaults to 50) - Fixed DBMD.supportsResultSetConcurrency() so that it returns true for ResultSet.TYPE_SCROLL_INSENSITIVE and ResultSet.CONCUR_READ_ONLY or ResultSet.CONCUR_UPDATABLE - Fixed ResultSet.isLast() for empty result sets (should return false). - PreparedStatement now honors stream lengths in setBinary/Ascii/Character Stream() unless you set the connection property 'useStreamLengthsInPrepStmts' to 'false'. - Removed some not-needed temporary object creation by using Strings smarter in EscapeProcessor, Connection and DatabaseMetaData classes. 09-21-02 - Version 3.0.1-dev - Fixed ResultSet.getRow() off-by-one bug. - Fixed RowDataStatic.getAt() off-by-one bug. - Added limited Clob functionality (ResultSet.getClob(), PreparedStatemtent.setClob(), PreparedStatement.setObject(Clob). - Added socketTimeout parameter to URL. - Connection.isClosed() no longer "pings" the server. - Connection.close() issues rollback() when getAutoCommit() == false - Added "paranoid" parameter...sanitizes error messages removing "sensitive" information from them (i.e. hostnames, ports, usernames, etc.), as well as clearing "sensitive" data structures when possible. - Fixed ResultSetMetaData.isSigned() for TINYINT and BIGINT. - Charsets now automatically detected. Optimized code for single-byte character set conversion. - Implemented ResultSet.getCharacterStream() - Added "LOCAL TEMPORARY" to table types in DatabaseMetaData.getTableTypes() - Massive code clean-up to follow Java coding conventions (the time had come) 07-31-02 - Version 3.0.0-dev - !!! LICENSE CHANGE !!! The driver is now GPL. If you need non-GPL licenses, please contact me <[email protected]> - JDBC-3.0 functionality including Statement/PreparedStatement.getGeneratedKeys() and ResultSet.getURL() - Performance enchancements - driver is now 50-100% faster in most situations, and creates fewer temporary objects - Repackaging...new driver name is "com.mysql.jdbc.Driver", old name still works, though (the driver is now provided by MySQL-AB) - Better checking for closed connections in Statement and PreparedStatement. - Support for streaming (row-by-row) result sets (see README) Thanks to Doron. - Support for large packets (new addition to MySQL-4.0 protocol), see README for more information. - JDBC Compliance -- Passes all tests besides stored procedure tests - Fix and sort primary key names in DBMetaData (SF bugs 582086 and 582086) - Float types now reported as java.sql.Types.FLOAT (SF bug 579573) - ResultSet.getTimestamp() now works for DATE types (SF bug 559134) - ResultSet.getDate/Time/Timestamp now recognizes all forms of invalid values that have been set to all zeroes by MySQL (SF bug 586058) - Testsuite now uses Junit (which you can get from www.junit.org) - The driver now only works with JDK-1.2 or newer. - Added multi-host failover support (see README) - General source-code cleanup. - Overall speed improvements via controlling transient object creation in MysqlIO class when reading packets - Performance improvements in string handling and field metadata creation (lazily instantiated) contributed by Alex Twisleton-Wykeham-Fiennes 05-16-02 - Version 2.0.14 - More code cleanup - PreparedStatement now releases resources on .close() (SF bug 553268) - Quoted identifiers not used if server version does not support them. Also, if server started with --ansi or --sql-mode=ANSI_QUOTES then '"' will be used as an identifier quote, otherwise '`' will be used. - ResultSet.getDouble() now uses code built into JDK to be more precise (but slower) - LogicalHandle.isClosed() calls through to physical connection - Added SQL profiling (to STDERR). Set "profileSql=true" in your JDBC url. See README for more information. - Fixed typo for relaxAutoCommit parameter. 04-24-02 - Version 2.0.13 - More code cleanup. - Fixed unicode chars being read incorrectly (SF bug 541088) - Faster blob escaping for PrepStmt - Added set/getPortNumber() to DataSource(s) (SF bug 548167) - Added setURL() to MySQLXADataSource (SF bug 546019) - PreparedStatement.toString() fixed (SF bug 534026) - ResultSetMetaData.getColumnClassName() now implemented - Rudimentary version of Statement.getGeneratedKeys() from JDBC-3.0 now implemented (you need to be using JDK-1.4 for this to work, I believe) - DBMetaData.getIndexInfo() - bad PAGES fixed (SF BUG 542201) 04-07-02 - Version 2.0.12 - General code cleanup. - Added getIdleFor() method to Connection and MysqlLogicalHandle. - Relaxed synchronization in all classes, should fix 520615 and 520393. - Added getTable/ColumnPrivileges() to DBMD (fixes 484502). - Added new types to getTypeInfo(), fixed existing types thanks to Al Davis and Kid Kalanon. - Added support for BIT types (51870) to PreparedStatement. - Fixed getRow() bug (527165) in ResultSet - Fixes for ResultSet updatability in PreparedStatement. - Fixed timezone off by 1-hour bug in PreparedStatement (538286, 528785). - ResultSet: Fixed updatability (values being set to null if not updated). - DataSources - fixed setUrl bug (511614, 525565), wrong datasource class name (532816, 528767) - Added identifier quoting to all DatabaseMetaData methods that need them (should fix 518108) - Added support for YEAR type (533556) - ResultSet.insertRow() should now detect auto_increment fields in most cases and use that value in the new row. This detection will not work in multi-valued keys, however, due to the fact that the MySQL protocol does not return this information. - ResultSet.refreshRow() implemented. - Fixed testsuite.Traversal afterLast() bug, thanks to Igor Lastric. 01-27-02 - Version 2.0.11 - Fixed missing DELETE_RULE value in DBMD.getImported/ExportedKeys() and getCrossReference(). - Full synchronization of Statement.java. - More changes to fix "Unexpected end of input stream" errors when reading BLOBs. This should be the last fix. 01-24-02 - Version 2.0.10 - Fixed spurious "Unexpected end of input stream" errors in MysqlIO (bug 507456). - Fixed null-pointer-exceptions when using MysqlConnectionPoolDataSource with Websphere 4 (bug 505839). 01-13-02 - Version 2.0.9 - Ant build was corrupting included jar files, fixed (bug 487669). - Fixed extra memory allocation in MysqlIO.readPacket() (bug 488663). - Implementation of DatabaseMetaData.getExported/ImportedKeys() and getCrossReference(). - Full synchronization on methods modifying instance and class-shared references, driver should be entirely thread-safe now (please let me know if you have problems) - DataSource implementations moved to org.gjt.mm.mysql.jdbc2.optional package, and (initial) implementations of PooledConnectionDataSource and XADataSource are in place (thanks to Todd Wolff for the implementation and testing of PooledConnectionDataSource with IBM WebSphere 4). - Added detection of network connection being closed when reading packets (thanks to Todd Lizambri). - Fixed quoting error with escape processor (bug 486265). - Report batch update support through DatabaseMetaData (bug 495101). - Fixed off-by-one-hour error in PreparedStatement.setTimestamp() (bug 491577). - Removed concatenation support from driver (the '||' operator), as older versions of VisualAge seem to be the only thing that use it, and it conflicts with the logical '||' operator. You will need to start mysqld with the "--ansi" flag to use the '||' operator as concatenation (bug 491680) - Fixed casting bug in PreparedStatement (bug 488663). 11-25-01 - Version 2.0.8 - Batch updates now supported (thanks to some inspiration from Daniel Rall). - XADataSource/ConnectionPoolDataSource code (experimental) - PreparedStatement.setAnyNumericType() now handles positive exponents correctly (adds "+" so MySQL can understand it). - DatabaseMetaData.getPrimaryKeys() and getBestRowIdentifier() are now more robust in identifying primary keys (matches regardless of case or abbreviation/full spelling of Primary Key in Key_type column). 10-24-01 - Version 2.0.7 - PreparedStatement.setCharacterStream() now implemented - Fixed dangling socket problem when in high availability (autoReconnect=true) mode, and finalizer for Connection will close any dangling sockets on GC. - Fixed ResultSetMetaData.getPrecision() returning one less than actual on newer versions of MySQL. - ResultSet.getBlob() now returns null if column value was null. - Character sets read from database if useUnicode=true and characterEncoding is not set. (thanks to Dmitry Vereshchagin) - Initial transaction isolation level read from database (if avaialable) (thanks to Dmitry Vereshchagin) - Fixed DatabaseMetaData.supportsTransactions(), and supportsTransactionIsolationLevel() and getTypeInfo() SQL_DATETIME_SUB and SQL_DATA_TYPE fields not being readable. - Fixed PreparedStatement generating SQL that would end up with syntax errors for some queries. - Fixed ResultSet.isAfterLast() always returning false. - Fixed timezone issue in PreparedStatement.setTimestamp() (thanks to Erik Olofsson) - Captialize type names when "captializeTypeNames=true" is passed in URL or properties (for WebObjects, thanks to Anjo Krank) - Updatable result sets now correctly handle NULL values in fields. - PreparedStatement.setDouble() now uses full-precision doubles (reverting a fix made earlier to truncate them). - PreparedStatement.setBoolean() will use 1/0 for values if your MySQL Version >= 3.21.23. 06-16-01 - Version 2.0.6 - Fixed PreparedStatement parameter checking - Fixed case-sensitive column names in ResultSet.java 06-13-01 - Version 2.0.5 - Fixed ResultSet.getBlob() ArrayIndex out-of-bounds - Fixed ResultSetMetaData.getColumnTypeName for TEXT/BLOB - Fixed ArrayIndexOutOfBounds when sending large BLOB queries (Max size packet was not being set) - Added ISOLATION level support to Connection.setIsolationLevel() - Fixed NPE on PreparedStatement.executeUpdate() when all columns have not been set. - Fixed data parsing of TIMESTAMPs with 2-digit years - Added Byte to PreparedStatement.setObject() - ResultSet.getBoolean() now recognizes '-1' as 'true' - ResultSet has +/-Inf/inf support - ResultSet.insertRow() works now, even if not all columns are set (they will be set to "NULL") - DataBaseMetaData.getCrossReference() no longer ArrayIndexOOB - getObject() on ResultSet correctly does TINYINT->Byte and SMALLINT->Short 12-03-00 - Version 2.0.3 - Implemented getBigDecimal() without scale component for JDBC2. - Fixed composite key problem with updateable result sets. - Added detection of -/+INF for doubles. - Faster ASCII string operations. - Fixed incorrect detection of MAX_ALLOWED_PACKET, so sending large blobs should work now. - Fixed off-by-one error in java.sql.Blob implementation code. - Added "ultraDevHack" URL parameter, set to "true" to allow (broken) Macromedia UltraDev to use the driver. 04-06-00 - Version 2.0.1 - Fixed RSMD.isWritable() returning wrong value. Thanks to Moritz Maass. - Cleaned up exception handling when driver connects - Columns that are of type TEXT now return as Strings when you use getObject() - DatabaseMetaData.getPrimaryKeys() now works correctly wrt to key_seq. Thanks to Brian Slesinsky. - No escape processing is done on PreparedStatements anymore per JDBC spec. - Fixed many JDBC-2.0 traversal, positioning bugs, especially wrt to empty result sets. Thanks to Ron Smits, Nick Brook, Cessar Garcia and Carlos Martinez. - Fixed some issues with updatability support in ResultSet when using multiple primary keys. 02-21-00 - Version 2.0pre5 - Fixed Bad Handshake problem. 01-10-00 - Version 2.0pre4 - Fixes to ResultSet for insertRow() - Thanks to Cesar Garcia - Fix to Driver to recognize JDBC-2.0 by loading a JDBC-2.0 class, instead of relying on JDK version numbers. Thanks to John Baker. - Fixed ResultSet to return correct row numbers - Statement.getUpdateCount() now returns rows matched, instead of rows actually updated, which is more SQL-92 like. 10-29-99 - Statement/PreparedStatement.getMoreResults() bug fixed. Thanks to Noel J. Bergman. - Added Short as a type to PreparedStatement.setObject(). Thanks to Jeff Crowder - Driver now automagically configures maximum/preferred packet sizes by querying server. - Autoreconnect code uses fast ping command if server supports it. - Fixed various bugs wrt. to packet sizing when reading from the server and when alloc'ing to write to the server. 08-17-99 - Version 2.0pre - Now compiles under JDK-1.2. The driver supports both JDK-1.1 and JDK-1.2 at the same time through a core set of classes. The driver will load the appropriate interface classes at runtime by figuring out which JVM version you are using. - Fixes for result sets with all nulls in the first row. (Pointed out by Tim Endres) - Fixes to column numbers in SQLExceptions in ResultSet (Thanks to Blas Rodriguez Somoza) - The database no longer needs to specified to connect. (Thanks to Christian Motschke) 07-04-99 - Version 1.2b - Better Documentation (in progress), in doc/mm.doc/book1.html - DBMD now allows null for a column name pattern (not in spec), which it changes to '%'. - DBMD now has correct types/lengths for getXXX(). - ResultSet.getDate(), getTime(), and getTimestamp() fixes. (contributed by Alan Wilken) - EscapeProcessor now handles \{ \} and { or } inside quotes correctly. (thanks to Alik for some ideas on how to fix it) - Fixes to properties handling in Connection. (contributed by Juho Tikkala) - ResultSet.getObject() now returns null for NULL columns in the table, rather than bombing out. (thanks to Ben Grosman) - ResultSet.getObject() now returns Strings for types from MySQL that it doesn't know about. (Suggested by Chris Perdue) - Removed DataInput/Output streams, not needed, 1/2 number of method calls per IO operation. - Use default character encoding if one is not specified. This is a work-around for broken JVMs, because according to spec, EVERY JVM must support "ISO8859_1", but they don't. - Fixed Connection to use the platform character encoding instead of "ISO8859_1" if one isn't explicitly set. This fixes problems people were having loading the character- converter classes that didn't always exist (JVM bug). (thanks to Fritz Elfert for pointing out this problem) - Changed MysqlIO to re-use packets where possible to reduce memory usage. - Fixed escape-processor bugs pertaining to {} inside quotes. 04-14-99 - Version 1.2a - Fixed character-set support for non-Javasoft JVMs (thanks to many people for pointing it out) - Fixed ResultSet.getBoolean() to recognize 'y' & 'n' as well as '1' & '0' as boolean flags. (thanks to Tim Pizey) - Fixed ResultSet.getTimestamp() to give better performance. (thanks to Richard Swift) - Fixed getByte() for numeric types. (thanks to Ray Bellis) - Fixed DatabaseMetaData.getTypeInfo() for DATE type. (thanks to Paul Johnston) - Fixed EscapeProcessor for "fn" calls. (thanks to Piyush Shah at locomotive.org) - Fixed EscapeProcessor to not do extraneous work if there are no escape codes. (thanks to Ryan Gustafson) - Fixed Driver to parse URLs of the form "jdbc:mysql://host:port" (thanks to Richard Lobb) 03-24-99 - Version 1.1i - Fixed Timestamps for PreparedStatements - Fixed null pointer exceptions in RSMD and RS - Re-compiled with jikes for valid class files (thanks ms!) 03-08-99 - Version 1.1h - Fixed escape processor to deal with un-matched { and } (thanks to Craig Coles) - Fixed escape processor to create more portable (between DATETIME and TIMESTAMP types) representations so that it will work with BETWEEN clauses. (thanks to Craig Longman) - MysqlIO.quit() now closes the socket connection. Before, after many failed connections some OS's would run out of file descriptors. (thanks to Michael Brinkman) - Fixed NullPointerException in Driver.getPropertyInfo. (thanks to Dave Potts) - Fixes to MysqlDefs to allow all *text fields to be retrieved as Strings. (thanks to Chris at Leverage) - Fixed setDouble in PreparedStatement for large numbers to avoid sending scientific notation to the database. (thanks to J.S. Ferguson) - Fixed getScale() and getPrecision() in RSMD. (contrib'd by James Klicman) - Fixed getObject() when field was DECIMAL or NUMERIC (thanks to Bert Hobbs) - DBMD.getTables() bombed when passed a null table-name pattern. Fixed. (thanks to Richard Lobb) - Added check for "client not authorized" errors during connect. (thanks to Hannes Wallnoefer) 02-19-99 - Version 1.1g - Result set rows are now byte arrays. Blobs and Unicode work bidriectonally now. The useUnicode and encoding options are implemented now. - Fixes to PreparedStatement to send binary set by setXXXStream to be sent un-touched to the MySQL server. - Fixes to getDriverPropertyInfo(). 12-31-98 - Version 1.1f - Changed all ResultSet fields to Strings, this should allow Unicode to work, but your JVM must be able to convert between the character sets. This should also make reading data from the server be a bit quicker, because there is now no conversion from StringBuffer to String. - Changed PreparedStatement.streamToString() to be more efficient (code from Uwe Schaefer). - URL parsing is more robust (throws SQL exceptions on errors rather than NullPointerExceptions) - PreparedStatement now can convert Strings to Time/Date values via setObject() (code from Robert Currey). - IO no longer hangs in Buffer.readInt(), that bug was introduced in 1.1d when changing to all byte-arrays for result sets. (Pointed out by Samo Login) 11-03-98 - Version 1.1b - Fixes to DatabaseMetaData to allow both IBM VA and J-Builder to work. Let me know how it goes. (thanks to Jac Kersing) - Fix to ResultSet.getBoolean() for NULL strings (thanks to Barry Lagerweij) - Beginning of code cleanup, and formatting. Getting ready to branch this off to a parallel JDBC-2.0 source tree. - Added "final" modifier to critical sections in MysqlIO and Buffer to allow compiler to inline methods for speed. 9-29-98 - If object references passed to setXXX() in PreparedStatement are null, setNull() is automatically called for you. (Thanks for the suggestion goes to Erik Ostrom) - setObject() in PreparedStatement will now attempt to write a serialized representation of the object to the database for objects of Types.OTHER and objects of unknown type. - Util now has a static method readObject() which given a ResultSet and a column index will re-instantiate an object serialized in the above manner. 9-02-98 - Vesion 1.1 - Got rid of "ugly hack" in MysqlIO.nextRow(). Rather than catch an exception, Buffer.isLastDataPacket() was fixed. - Connection.getCatalog() and Connection.setCatalog() should work now. - Statement.setMaxRows() works, as well as setting by property maxRows. Statement.setMaxRows() overrides maxRows set via properties or url parameters. - Automatic re-connection is available. Because it has to "ping" the database before each query, it is turned off by default. To use it, pass in "autoReconnect=true" in the connection URL. You may also change the number of reconnect tries, and the initial timeout value via "maxReconnects=n" (default 3) and "initialTimeout=n" (seconds, default 2) parameters. The timeout is an exponential backoff type of timeout, e.g. if you have initial timeout of 2 seconds, and maxReconnects of 3, then the driver will timeout 2 seconds, 4 seconds, then 16 seconds between each re-connection attempt. 8-24-98 - Version 1.0 - Fixed handling of blob data in Buffer.java - Fixed bug with authentication packet being sized too small. - The JDBC Driver is now under the LPGL 8-14-98 - - Fixed Buffer.readLenString() to correctly read data for BLOBS. - Fixed PreparedStatement.stringToStream to correctly read data for BLOBS. - Fixed PreparedStatement.setDate() to not add a day. (above fixes thanks to Vincent Partington) - Added URL parameter parsing (?user=... etc). 8-04-98 - Version 0.9d - Big news! New package name. Tim Endres from ICE Engineering is starting a new source tree for GNU GPL'd Java software. He's graciously given me the org.gjt.mm package directory to use, so now the driver is in the org.gjt.mm.mysql package scheme. I'm "legal" now. Look for more information on Tim's project soon. - Now using dynamically sized packets to reduce memory usage when sending commands to the DB. - Small fixes to getTypeInfo() for parameters, etc. - DatabaseMetaData is now fully implemented. Let me know if these drivers work with the various IDEs out there. I've heard that they're working with JBuilder right now. - Added JavaDoc documentation to the package. - Package now available in .zip or .tar.gz. 7-28-98 - Version 0.9 - Implemented getTypeInfo(). Connection.rollback() now throws an SQLException per the JDBC spec. - Added PreparedStatement that supports all JDBC API methods for PreparedStatement including InputStreams. Please check this out and let me know if anything is broken. - Fixed a bug in ResultSet that would break some queries that only returned 1 row. - Fixed bugs in DatabaseMetaData.getTables(), DatabaseMetaData.getColumns() and DatabaseMetaData.getCatalogs(). - Added functionality to Statement that allows executeUpdate() to store values for IDs that are automatically generated for AUTO_INCREMENT fields. Basically, after an executeUpdate(), look at the SQLWarnings for warnings like "LAST_INSERTED_ID = 'some number', COMMAND = 'your SQL query'". If you are using AUTO_INCREMENT fields in your tables and are executing a lot of executeUpdate()s on one Statement, be sure to clearWarnings() every so often to save memory. 7-06-98 - Version 0.8 - Split MysqlIO and Buffer to separate classes. Some ClassLoaders gave an IllegalAccess error for some fields in those two classes. Now mm.mysql works in applets and all classloaders. Thanks to Joe Ennis <[email protected]> for pointing out the problem and working on a fix with me. 7-01-98 - Version 0.7 - Fixed DatabaseMetadata problems in getColumns() and bug in switch statement in the Field constructor. Thanks to Costin Manolache <[email protected]> for pointing these out. 5-21-98 - Version 0.6 - Incorporated efficiency changes from Richard Swift <[email protected]> in MysqlIO.java and ResultSet.java - We're now 15% faster than gwe's driver. - Started working on DatabaseMetaData. The following methods are implemented: * getTables() * getTableTypes() * getColumns * getCatalogs()