db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject DatabaseMetaData JDBC specification question
Date Tue, 16 Jan 2007 16:49:03 GMT
For the DatabaseMetaData methods that fetch attributes of SQL objects 
(such as getTables, getColumns) the parameters are described in the 
javadoc in three ways:

1) Parameter must match the object's name as stored in the database.

<example javadoc quote>
a table name; must match the table name as it is stored in the database
</example javadoc quote>

2) Parameter must match the object's name as stored in the database and 
two special values are allowed (empty string and null).

<example javadoc quote>
a schema name; must match the schema name as it is stored in the 
database; "" retrieves those without a schema; null means that the 
schema name should not be used to narrow the search
</example javadoc quote>

3) A pattern, explicitly called out in the overview of DatabaseMetaData 
and states the parameter name will end in 'pattern'.

<example javadoc quote>
a table name pattern; must match the table name as it is stored in the 
database
</example javadoc quote>

These imply very different behaviours for the various styles, e.g.

for 1) null should not be allowed and the value should not be treated as 
a pattern or use empty string to indicate those without a schema.

for 2) the value should not be treated as a pattern.

Derby does not follow this split, it treats every such argument as a 
pattern (in some cases the client may treat arguments differently).

Is the split in DatabaseMetaData intentional, it seems so given the 
explicit wording for patterns? And the fact that in some cases the 
method's description indicates information for 'a table' (singular) is 
returned and the resulting rows have no information that allows one to 
determine which table a row is for (e.g getBestRowIdentifier & 
getVersionColumns). Though in both those cases the api also implicitly 
allows for multiple tables to be returned when the same table name 
exists in multiple schemas.

If so should Derby follow the strict definitions of the javadoc or could 
Derby just be providing extensions to the standard behaviour?
The only area where I could see issues coming up with this extension is 
when the parameter is in category 1) or 2) and the object name contains 
'%' or '_'. Then a meta data call could potentially return rows for 
other tables and in some cases the meta data provides no way to 
determine which table a row is for (e.g getBestRowIdentifier & 
getVersionColumns).

One other point is that removing the pattern support from a number of 
meta data queries would most likely improve their performance.

Thanks,
Dan.



Mime
View raw message