db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland <Jorgen.Lol...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-1484) Client and embedded behave differently when the table name is null in DatabaseMetaData methods
Date Mon, 07 May 2007 07:28:22 GMT
Myrna van Lunteren wrote:
> Jørgen,
> I think a Release note is needed for every change that actually
> changes behavior - incl. undocumented  and incorrect behavior.
> Release Notes are a help to users to identify those changes in
> behavior that could impact them when upgrading.
> Needing a release note for a subtask, or a test, or documentation
> change is debatable, but I think this one could have a short release
> note. Please see DERBY-2570 for the template.
> 
> Thx,
> Myrna
> 

Thank you for commenting on this, Myrna.

ReleaseNote text attempt:

Summary of Change
Tablenames can no longer be null in calls to DatabaseMetaData methods 
getBestRowIdentifier(), getColumnPrivileges(), getIndexInfo(), 
getVersionColumns(), getPrimaryKeys(), getImportedKeys() and 
getExportedKeys().

*Comment: The above is a rather long one-liner, but I think all the 
information is required*

Symptoms Seen by Applications Affected by Change
In the previous release, the methods returned information on all tables 
in the schema if the tablename parameter was null. Derby now raises an 
SQLException if the tablename is null.

Incompatibilities with Previous Release
Calls to the specified methods now fail if the tablename parameter is null.

Rationale for Change
The previous behavior violated the JDBC standard. The new behavior is 
correct.

Application Changes Required
Users must recode applications to specify the table names. When 
information on multiple tables is required, the application first has to 
get the table names, e.g. by using the DatabaseMetaData method 
getTables(), and then use the returned table names as input to the 
method in question.

Mime
View raw message