Mapping SQL Data to Java
One tricky subject that you need to be aware of when using JDBCs to access database is that data types in SQL don’t correspond exactly to Java Data Types. Indeed there are also significant variations between the SQL types supported by different database products. Even when different database support SQL types with the same semantics, they may give those types different names.
For Example:
Most of the major databases support a SQL data type for large binary values, but Oracle calls this type LONG RAW, Sybase calls it IMAGE, Informix calls it BYTE, and DB2 calls it LONG VARCHAR FOR BIT DATA.
JDBC defines a set of generic SQL type identifiers in the class “java.sql.Types”. These types have been designed to represent the most commonly used SQL types. While programing with the JDBC API, we have to use these JDBC types to reference generic SQL types, without having to concern yourself with the exact SQL type name used by the target database.
If we write portable JDBC program that can create tables on a variety of different databases, we will faced with two choices:
Ø First, we can restrict our self to using only very widely accepted SQL type names such as INTEGER, FLOAT, or VARCHAR, which are likely to work for all databases.
Ø Second, we can use the “java.sql.DatabaseMetaData.getTypeInfo()” method to discover which SQL types are actually supported by a given database, ad select a data-specific SQL type name that matches a given JDBC type.
The following table illustrates the general correspondence between Java data types and SQL types:
Java Type | Sql type |
String | char, varchar, or longvarchar |
java.math.Bigdecimal | numeric |
boolean | bit |
byte | tinyint |
short | smallint |
int | integer |
long | bigint |
float | real |
double | double |
byte[] | binary, varbinary, or longvarbinary |
java.sql.Date | date |
java.sql.Time | time |
java.sql.Timestamp | timestamp |
Clob | clob |
Blob | blob |
Array | array |
Struct | struct |
Ref | ref |
Java class | java_object |
Database Connection
The main classes and interface traditionally involved in making a connection to the database are:
Ø The “java.sql.Driver” interfaceà Responds to connection requests from the DriverManager and provide information about its implementation.
Ø The “java.sql.DriverManager” classà Maintains a list of Driver implementations.
Ø The “java.sql.Connection” interfaceà Represents a single logical database connection.
There are two way of Driver loading. The Drivers are loaded by setting the jdbc.drivers system property or by using the “Class.forname()” method call.
The process of passing a driver name and the URL from obtaining a connection seems to be unnecessarily complex when we are trying to write database independent code. Details like registering driver should be abstracted away from the application, and this is made possible with the Java Naming and Directory interface (JNDI) and the JDBC Optional Package.
Java Naming and Directory Interface
The Java Naming and Directory interface (JNDI) is the Java API that allows us to access naming and directory services in the transparent way. The JNDI architecture consists of an API and a Service Provider Interface (SPI). Java applications use the JNDI API to access a variety of naming and directory services. The JNDI SPI enables a variety of naming and directory services to be plugged in transparently, thereby allowing the java application using the JNDI API to access their services.
The JNDI PI is divided into five Java Packages:
Ø “javax.naming”
ü The “javax.naming” package contains class and interfaces for accessing naming services. This package define a context interface, which is the core interface for looking up, binding/unbinding, renaming objects, and creating and destroying subcontexts. The most commonly used operation is
v lookup() à It used to find the name of object we want to look up, and returns the object bounded to that name.
Ø “javax.naming.directory”
ü The “javax.naming.directory” package extends the “javax.naming” package to provide functionality for accessing directory services in addition to naming services.
ü This package allows applications to retrieve attributes associated with objects stored in the directory and to search for objects using specified attributes. The commonly used method:
v getAttributes() à It used to retrieve the attributes associated with a directory object.
v modifyAttributes() à This method allowing to add, replace, and or modify attributes ad their variables
Ø “javax.naming.event”
ü The “javax.naming.event” package contains classes and interface for supporting event notification in naming and directory services.
Ø “javax.naming.ldap”
ü The “javax.naming.ldap” package contains class and interfaces for using features that are specific to LDAP that are not already covered by the more generic “javax.naming.directory” package.
ü The most of JNDI find “javax.naming.directory” package sufficient at all, no need to use “javax.naming.ldap” package at all.
ü The main purpose of using “javax.naming.ldap” package is primarily for those applications that need to use extended operations, controls, or unsolicited notification.
Ø “java.naming.spi”
ü The “java.naming.spi” package provides the means by which developers of different naming/directory service providers can develop and hook up their implementation so that the corresponding services are accessible from applications that use JNDI.
ü This package allows different implementations to be plugged in dynamically.
ü These implementations include those for the initial context and for contexts that can be reached from the initial context.
