You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2006/02/02 18:16:13 UTC
Returning an empty result set
According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.
Can anyone provide me some guidance as to the best way to do this? The
constructor for org.apache.derby.client.am.ResultSet requires a lot of
parameters that I don't want to try and create, and the same is true for
the engine.
And a question to Lance: does it really make sense for getSchemas() and
getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?
Thanks,
David
Re: Returning an empty result set
Posted by "Lance J. Andersen" <La...@Sun.COM>.
The client network driver has, we do it internally.
David W. Van Couvering wrote:
> Lance -- it appears that Derby has not been run through the
> conformance tests. How does one go about doing that? I would think
> that's pretty important.
>
> Thanks,
>
> David
>
> Lance J. Andersen wrote:
>
>> The JDBC spec requires DatabaseMetaData to be fully implemented.
>>
>> For non DatabaseMetaData methods not implement and not required, a
>> SQLException must be thrown and in the case of JDBC 4.0
>> SQLFeatureNotSupportedException must be thrown.
>>
>>
>> Any drivers which fail to implement DatabaseMetaData methods and
>> throw an Exception would not pass the conformance tests.
>>
>>
>> HTH
>>
>> Lance
>>
>>
>>
>>
>> David W. Van Couvering wrote:
>>
>>> Great question. Odd answer.
>>>
>>> Things are not coherent, as far as I can tell, between the network
>>> driver and the embedded driver.
>>>
>>> == getUDTs() ==
>>>
>>> *** network driver ***
>>>
>>> call SYSIBM.SQLUDTS(?,?,?,?,?)
>>>
>>> *** embedded driver ***
>>>
>>> throw Util.notImplemented()
>>>
>>> == getSuperTypes() ==
>>>
>>> *** network driver ***
>>>
>>> String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
>>> "CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
>>> "VARCHAR('', 128) AS TYPE_NAME," +
>>> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
>>> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
>>> "VARCHAR('', 128) AS SUPERTYPE_NAME " +
>>> "FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";
>>>
>>> *** embedded driver ***
>>>
>>> throw Util.notImplemented()
>>>
>>> ====
>>>
>>> So, I'm at a bit of a loss. Can anyone explain the history of this
>>> and what the "right" thing to do is. Barring any other feedback, it
>>> would appear that the embedded driver is out-of-date and needs
>>> updating to do what the client driver does. Another case where code
>>> sharing could be quite useful...
>>>
>>> And, Lance, is it really true that every metadata call has to return
>>> a real result rather than throw a "Feature not implemented" exception?
>>>
>>> David
>>>
>>> Lance J. Andersen wrote:
>>>
>>>>
>>>>
>>>> David W. Van Couvering wrote:
>>>>
>>>>> According to our most esteemed spec lead, for the new metadata calls
>>>>> that return a result set, if we don't support the metadata call, we
>>>>> should return an empty result set.
>>>>>
>>>>> Can anyone provide me some guidance as to the best way to do
>>>>> this? The
>>>>> constructor for org.apache.derby.client.am.ResultSet requires a
>>>>> lot of
>>>>> parameters that I don't want to try and create, and the same is
>>>>> true for
>>>>> the engine.
>>>>>
>>>>> And a question to Lance: does it really make sense for
>>>>> getSchemas() and
>>>>> getClientInfoProperties() to return an empty result set, isn't that a
>>>>> bit misleading?
>>>>>
>>>> Hi Dave,
>>>>
>>>> There is already a precedent for this type of behavior. getUDTS(),
>>>> getSuperTypes() are an example
>>>>
>>>> regards
>>>> lance
>>>> (your friendly neighborhood spec lead....)
>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
Re: Returning an empty result set
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Lance -- it appears that Derby has not been run through the conformance
tests. How does one go about doing that? I would think that's pretty
important.
Thanks,
David
Lance J. Andersen wrote:
> The JDBC spec requires DatabaseMetaData to be fully implemented.
>
> For non DatabaseMetaData methods not implement and not required, a
> SQLException must be thrown and in the case of JDBC 4.0
> SQLFeatureNotSupportedException must be thrown.
>
>
> Any drivers which fail to implement DatabaseMetaData methods and throw
> an Exception would not pass the conformance tests.
>
>
> HTH
>
> Lance
>
>
>
>
> David W. Van Couvering wrote:
>
>> Great question. Odd answer.
>>
>> Things are not coherent, as far as I can tell, between the network
>> driver and the embedded driver.
>>
>> == getUDTs() ==
>>
>> *** network driver ***
>>
>> call SYSIBM.SQLUDTS(?,?,?,?,?)
>>
>> *** embedded driver ***
>>
>> throw Util.notImplemented()
>>
>> == getSuperTypes() ==
>>
>> *** network driver ***
>>
>> String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
>> "CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
>> "VARCHAR('', 128) AS TYPE_NAME," +
>> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
>> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
>> "VARCHAR('', 128) AS SUPERTYPE_NAME " +
>> "FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";
>>
>> *** embedded driver ***
>>
>> throw Util.notImplemented()
>>
>> ====
>>
>> So, I'm at a bit of a loss. Can anyone explain the history of this
>> and what the "right" thing to do is. Barring any other feedback, it
>> would appear that the embedded driver is out-of-date and needs
>> updating to do what the client driver does. Another case where code
>> sharing could be quite useful...
>>
>> And, Lance, is it really true that every metadata call has to return a
>> real result rather than throw a "Feature not implemented" exception?
>>
>> David
>>
>> Lance J. Andersen wrote:
>>
>>>
>>>
>>> David W. Van Couvering wrote:
>>>
>>>> According to our most esteemed spec lead, for the new metadata calls
>>>> that return a result set, if we don't support the metadata call, we
>>>> should return an empty result set.
>>>>
>>>> Can anyone provide me some guidance as to the best way to do this? The
>>>> constructor for org.apache.derby.client.am.ResultSet requires a lot of
>>>> parameters that I don't want to try and create, and the same is true
>>>> for
>>>> the engine.
>>>>
>>>> And a question to Lance: does it really make sense for getSchemas() and
>>>> getClientInfoProperties() to return an empty result set, isn't that a
>>>> bit misleading?
>>>>
>>> Hi Dave,
>>>
>>> There is already a precedent for this type of behavior. getUDTS(),
>>> getSuperTypes() are an example
>>>
>>> regards
>>> lance
>>> (your friendly neighborhood spec lead....)
>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
Re: Returning an empty result set
Posted by Daniel John Debrunner <dj...@apache.org>.
David W. Van Couvering wrote:
> Well, then, I think we have a bug in EmbedDatabaseMetadata,
> EmbedDatabaseMetadata40, and NetDatabaesMetadata40. I'll log JIRA items.
>
> I also noticed that getSuperTypes() in the network client does what I
> need to do: it calls a "fake" query on the server, and then returns what
> must be an empty result set. I'll use that approach where necessary.
This is done for emebdded as well, see getCatalogs(), maybe just not all
the DMD methods where an empty result set could be return.
Dan.
Re: Returning an empty result set
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Well, then, I think we have a bug in EmbedDatabaseMetadata,
EmbedDatabaseMetadata40, and NetDatabaesMetadata40. I'll log JIRA items.
I also noticed that getSuperTypes() in the network client does what I
need to do: it calls a "fake" query on the server, and then returns what
must be an empty result set. I'll use that approach where necessary.
David
Lance J. Andersen wrote:
> The JDBC spec requires DatabaseMetaData to be fully implemented.
>
> For non DatabaseMetaData methods not implement and not required, a
> SQLException must be thrown and in the case of JDBC 4.0
> SQLFeatureNotSupportedException must be thrown.
>
>
> Any drivers which fail to implement DatabaseMetaData methods and throw
> an Exception would not pass the conformance tests.
>
>
> HTH
>
> Lance
>
>
>
>
> David W. Van Couvering wrote:
>
>> Great question. Odd answer.
>>
>> Things are not coherent, as far as I can tell, between the network
>> driver and the embedded driver.
>>
>> == getUDTs() ==
>>
>> *** network driver ***
>>
>> call SYSIBM.SQLUDTS(?,?,?,?,?)
>>
>> *** embedded driver ***
>>
>> throw Util.notImplemented()
>>
>> == getSuperTypes() ==
>>
>> *** network driver ***
>>
>> String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
>> "CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
>> "VARCHAR('', 128) AS TYPE_NAME," +
>> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
>> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
>> "VARCHAR('', 128) AS SUPERTYPE_NAME " +
>> "FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";
>>
>> *** embedded driver ***
>>
>> throw Util.notImplemented()
>>
>> ====
>>
>> So, I'm at a bit of a loss. Can anyone explain the history of this
>> and what the "right" thing to do is. Barring any other feedback, it
>> would appear that the embedded driver is out-of-date and needs
>> updating to do what the client driver does. Another case where code
>> sharing could be quite useful...
>>
>> And, Lance, is it really true that every metadata call has to return a
>> real result rather than throw a "Feature not implemented" exception?
>>
>> David
>>
>> Lance J. Andersen wrote:
>>
>>>
>>>
>>> David W. Van Couvering wrote:
>>>
>>>> According to our most esteemed spec lead, for the new metadata calls
>>>> that return a result set, if we don't support the metadata call, we
>>>> should return an empty result set.
>>>>
>>>> Can anyone provide me some guidance as to the best way to do this? The
>>>> constructor for org.apache.derby.client.am.ResultSet requires a lot of
>>>> parameters that I don't want to try and create, and the same is true
>>>> for
>>>> the engine.
>>>>
>>>> And a question to Lance: does it really make sense for getSchemas() and
>>>> getClientInfoProperties() to return an empty result set, isn't that a
>>>> bit misleading?
>>>>
>>> Hi Dave,
>>>
>>> There is already a precedent for this type of behavior. getUDTS(),
>>> getSuperTypes() are an example
>>>
>>> regards
>>> lance
>>> (your friendly neighborhood spec lead....)
>>>
>>>> Thanks,
>>>>
>>>> David
>>>>
Re: Returning an empty result set
Posted by "Lance J. Andersen" <La...@Sun.COM>.
The JDBC spec requires DatabaseMetaData to be fully implemented.
For non DatabaseMetaData methods not implement and not required, a
SQLException must be thrown and in the case of JDBC 4.0
SQLFeatureNotSupportedException must be thrown.
Any drivers which fail to implement DatabaseMetaData methods and throw
an Exception would not pass the conformance tests.
HTH
Lance
David W. Van Couvering wrote:
> Great question. Odd answer.
>
> Things are not coherent, as far as I can tell, between the network
> driver and the embedded driver.
>
> == getUDTs() ==
>
> *** network driver ***
>
> call SYSIBM.SQLUDTS(?,?,?,?,?)
>
> *** embedded driver ***
>
> throw Util.notImplemented()
>
> == getSuperTypes() ==
>
> *** network driver ***
>
> String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
> "CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
> "VARCHAR('', 128) AS TYPE_NAME," +
> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
> "VARCHAR('', 128) AS SUPERTYPE_NAME " +
> "FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";
>
> *** embedded driver ***
>
> throw Util.notImplemented()
>
> ====
>
> So, I'm at a bit of a loss. Can anyone explain the history of this
> and what the "right" thing to do is. Barring any other feedback, it
> would appear that the embedded driver is out-of-date and needs
> updating to do what the client driver does. Another case where code
> sharing could be quite useful...
>
> And, Lance, is it really true that every metadata call has to return a
> real result rather than throw a "Feature not implemented" exception?
>
> David
>
> Lance J. Andersen wrote:
>
>>
>>
>> David W. Van Couvering wrote:
>>
>>> According to our most esteemed spec lead, for the new metadata calls
>>> that return a result set, if we don't support the metadata call, we
>>> should return an empty result set.
>>>
>>> Can anyone provide me some guidance as to the best way to do this? The
>>> constructor for org.apache.derby.client.am.ResultSet requires a lot of
>>> parameters that I don't want to try and create, and the same is true
>>> for
>>> the engine.
>>>
>>> And a question to Lance: does it really make sense for getSchemas() and
>>> getClientInfoProperties() to return an empty result set, isn't that a
>>> bit misleading?
>>>
>> Hi Dave,
>>
>> There is already a precedent for this type of behavior. getUDTS(),
>> getSuperTypes() are an example
>>
>> regards
>> lance
>> (your friendly neighborhood spec lead....)
>>
>>> Thanks,
>>>
>>> David
>>>
Re: Returning an empty result set
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Great question. Odd answer.
Things are not coherent, as far as I can tell, between the network
driver and the embedded driver.
== getUDTs() ==
*** network driver ***
call SYSIBM.SQLUDTS(?,?,?,?,?)
*** embedded driver ***
throw Util.notImplemented()
== getSuperTypes() ==
*** network driver ***
String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";
*** embedded driver ***
throw Util.notImplemented()
====
So, I'm at a bit of a loss. Can anyone explain the history of this and
what the "right" thing to do is. Barring any other feedback, it would
appear that the embedded driver is out-of-date and needs updating to do
what the client driver does. Another case where code sharing could be
quite useful...
And, Lance, is it really true that every metadata call has to return a
real result rather than throw a "Feature not implemented" exception?
David
Lance J. Andersen wrote:
>
>
> David W. Van Couvering wrote:
>
>> According to our most esteemed spec lead, for the new metadata calls
>> that return a result set, if we don't support the metadata call, we
>> should return an empty result set.
>>
>> Can anyone provide me some guidance as to the best way to do this? The
>> constructor for org.apache.derby.client.am.ResultSet requires a lot of
>> parameters that I don't want to try and create, and the same is true for
>> the engine.
>>
>> And a question to Lance: does it really make sense for getSchemas() and
>> getClientInfoProperties() to return an empty result set, isn't that a
>> bit misleading?
>>
> Hi Dave,
>
> There is already a precedent for this type of behavior. getUDTS(),
> getSuperTypes() are an example
>
> regards
> lance
> (your friendly neighborhood spec lead....)
>
>> Thanks,
>>
>> David
>>
Re: Returning an empty result set
Posted by "Lance J. Andersen" <La...@Sun.COM>.
David W. Van Couvering wrote:
> According to our most esteemed spec lead, for the new metadata calls
> that return a result set, if we don't support the metadata call, we
> should return an empty result set.
>
> Can anyone provide me some guidance as to the best way to do this? The
> constructor for org.apache.derby.client.am.ResultSet requires a lot of
> parameters that I don't want to try and create, and the same is true for
> the engine.
>
> And a question to Lance: does it really make sense for getSchemas() and
> getClientInfoProperties() to return an empty result set, isn't that a
> bit misleading?
>
Hi Dave,
There is already a precedent for this type of behavior. getUDTS(),
getSuperTypes() are an example
regards
lance
(your friendly neighborhood spec lead....)
> Thanks,
>
> David
>