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 Rick Hillegas <Ri...@Sun.COM> on 2005/11/08 22:55:10 UTC
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Hi Satheesh,
Thanks for tracking these proposals. Here are the datatypes I want to
add, re-enable, or extend in the 10.2 timeframe:
BOOLEAN
TINYINT
NCHAR
NVARCHAR
LONGNVARCHAR
NCLOB
ROWID
SQLXML
Cheers,
-Rick
Satheesh Bandaram wrote:
> I noticed several other new feature work being proposed and actively
> being worked, possibly in time for next 10.2 release. Here is the
> updated list I have so far. Let me know if I missed anything.
>
> 1. JDBC 4.0 Stub implementation
> 2. Unary Plus/Minus.
> 3. Code sharing proposal.
> 4. Optimizer hints
> 5. Timeout support in Derby client.
> 6. Grant/Revoke in Derby
> 7. I18 support and SQLStates for Derby client messages.
> 8. Updatable, scrollable result sets
> 9. New datatype(s) (Boolean)
> 10. Making FOR UPDATE optional
> 11. Online backup
> 12. XML enhancements for XPATH/XQuery support
> 13. setQueryTimeout for Derby client
> 14. ALTER Table DROP COLUMN
>
> Satheesh
>
> Dag H. Wanvik wrote:
>
>>>>>>>"Satheesh" == Satheesh Bandaram <sa...@Sourcery.Org> wrote:
>>>>>>>
>>>>>>>
>>
>>
>>
>>>Regarding "Long term" plans, as defined by DB project, I
>>>wonder what other enhancements DerbyDev folks are working
>>>on. I would like to know what else could be expected in the
>>>next 6 months. Some of other development efforts I know
>>>are:
>>>
>>> 1. JDBC 4.0 Stub implementation
>>> 2. Unary Plus/Minus.
>>> 3. Code sharing proposal.
>>> 4. Optimizer hints
>>> 5. Timeout support in Derby client.
>>> 6. Grant/Revoke in Derby
>>> 7. I18 support and SQLStates for Derby client messages.
>>>
>>>
>>
>>You can add:
>>
>>8. Updatable, scrollable result sets
>>
>>We (Fernanda, Andreas and I) are making progress on making the
>>scrollable (insensitive) result sets updatable, stay tuned.
>>
>>Dag
>>
>>
>>
>>
>>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
OK.. I will work on getting this info on a Wiki.
Satheesh
Daniel John Debrunner wrote:
>Satheesh Bandaram wrote:
>
><list of potential 10.2 features>
>
>This would be great to be on a wiki page, including links to the Jira
>entries with the functional specs. I'm losing track of which functional
>specs are out there, just saw in some reply that Dag has posted a
>functional spec on RowId (I think), must have missed the original note.
>
>
>Dan.
>
>
>
>
>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
>>>>> "Daniel" == Daniel John Debrunner <dj...@debrunners.com> wrote:
Daniel> This would be great to be on a wiki page, including links to the Jira
Daniel> entries with the functional specs. I'm losing track of which functional
Daniel> specs are out there, just saw in some reply that Dag has posted a
Daniel> functional spec on RowId (I think), must have missed the original note.
The func spec I posted was for scrollable, updatable result sets,
attached to JIRA 690
as http://issues.apache.org/jira/secure/attachment/12320548/sur-proposal.txt
Dag
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Satheesh Bandaram wrote:
<list of potential 10.2 features>
This would be great to be on a wiki page, including links to the Jira
entries with the functional specs. I'm losing track of which functional
specs are out there, just saw in some reply that Dag has posted a
functional spec on RowId (I think), must have missed the original note.
Dan.
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Hi Rick,
Rick Hillegas wrote:
> Hi Satheesh,
>
> TINYINT, as you note, is not an ANSI datatype. It is, however, a JDBC
> datatype and is supported by MySQL and SQL Server. Adding it would
> grow our JDBC support and help close the feature gap with some
> significant databases. I think those are compelling arguments.
I agree we have some reasons to support TINYINT, but also many reasons
not to support ... :-) SQL standard being the primary one. I am not
sure what Derby should do when two of its main specs differ (SQL spec Vs
JDBC spec), but I personally prefer to weigh more on the SQL spec since
Derby can be used from other clients as well. (ODBC, perl, .NET) Other
reasons would include lack of support from big vendors (DB2, Oracle,
Informix ...)
> ROWID is another JDBC type. to be added as part of the JDBC 4.0
> effort. It underlies the java.sql.RowId interface. Oracle calls these
> columns ROWIDs and Postgres calls them OIDs. This type needs some
> specifying.
>
Right... Oracle database has some support for ROWIDs, but Derby
currently doesn't. So what is the primary use of this time? I will wait
for your spec to know what useful functionality it adds...
> Enhancement requests 499 and 533 track the re-enabling of BOOLEAN and
> national character datatypes.
>
> TINYINT and ROWID deserve their own enhancement requests. I agree that
> an overall spec would be useful to make sure that we consistently
> handle the cross-release and client-server compatibility issues. I'll
> get around to this soon hopefully.
Thanks... Sooner the better, especially for debatable ideas/features...
Satheesh
>
> Cheers,
> -Rick
>
> Satheesh Bandaram wrote:
>
>> Hi Rick,
>>
>> Pretty interesting... I hope you will find time to make a detailed
>> proposal available for community review.
>>
>> SQL standard, as you probably know, doesn't support TINYINT or ROWID.
>> TINYINT especially is not defined by DB2, Oracle... Also, how are you
>> planning on defining ROWID and what is its main purpose?
>>
>> Hope you will share your thoughts early...
>>
>> Satheesh
>>
>> Rick Hillegas wrote:
>>
>>
>>
>>> Hi Satheesh,
>>>
>>> Thanks for tracking these proposals. Here are the datatypes I want to
>>> add, re-enable, or extend in the 10.2 timeframe:
>>>
>>> BOOLEAN
>>> TINYINT
>>> NCHAR
>>> NVARCHAR
>>> LONGNVARCHAR
>>> NCLOB
>>> ROWID
>>> SQLXML
>>>
>>> Cheers,
>>> -Rick
>>>
>>> Satheesh Bandaram wrote:
>>>
>>>
>>>
>>>> I noticed several other new feature work being proposed and actively
>>>> being worked, possibly in time for next 10.2 release. Here is the
>>>> updated list I have so far. Let me know if I missed anything.
>>>>
>>>> 1. JDBC 4.0 Stub implementation
>>>> 2. Unary Plus/Minus.
>>>> 3. Code sharing proposal.
>>>> 4. Optimizer hints
>>>> 5. Timeout support in Derby client.
>>>> 6. Grant/Revoke in Derby
>>>> 7. I18 support and SQLStates for Derby client messages.
>>>> 8. Updatable, scrollable result sets
>>>> 9. New datatype(s) (Boolean)
>>>> 10. Making FOR UPDATE optional
>>>> 11. Online backup
>>>> 12. XML enhancements for XPATH/XQuery support
>>>> 13. setQueryTimeout for Derby client
>>>> 14. ALTER Table DROP COLUMN
>>>>
>>>> Satheesh
>>>>
>>>> Dag H. Wanvik wrote:
>>>>
>>>>
>>>>
>>>>>>>>>> "Satheesh" == Satheesh Bandaram <sa...@Sourcery.Org> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regarding "Long term" plans, as defined by DB project, I
>>>>>> wonder what other enhancements DerbyDev folks are working
>>>>>> on. I would like to know what else could be expected in the
>>>>>> next 6 months. Some of other development efforts I know
>>>>>> are:
>>>>>>
>>>>>> 1. JDBC 4.0 Stub implementation
>>>>>> 2. Unary Plus/Minus.
>>>>>> 3. Code sharing proposal.
>>>>>> 4. Optimizer hints
>>>>>> 5. Timeout support in Derby client.
>>>>>> 6. Grant/Revoke in Derby
>>>>>> 7. I18 support and SQLStates for Derby client messages.
>>>>>>
>>>>>>
>>>>>
>>>>> You can add:
>>>>> 8. Updatable, scrollable result sets
>>>>>
>>>>> We (Fernanda, Andreas and I) are making progress on making the
>>>>> scrollable (insensitive) result sets updatable, stay tuned.
>>>>>
>>>>> Dag
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Rick Hillegas wrote:
> Hi Satheesh,
>
> TINYINT, as you note, is not an ANSI datatype. It is, however, a JDBC
> datatype and is supported by MySQL and SQL Server. Adding it would
> grow our JDBC support and help close the feature gap with some
> significant databases. I think those are compelling arguments.
> Fortunately, TINYINT is already supported by Derby--it was only
> lightly disabled when the non-DB2 datatypes were hidden. Re-enabling
> it should be easy.
Sybase also support this
>
> ROWID is another JDBC type. to be added as part of the JDBC 4.0
> effort. It underlies the java.sql.RowId interface. Oracle calls these
> columns ROWIDs and Postgres calls them OIDs. This type needs some
> specifying.
DB2 supports this as do other databases. MySQL has a special column
name __rowid which can be used if there is a Primary Key or Unique which
is an integer
>
> Enhancement requests 499 and 533 track the re-enabling of BOOLEAN and
> national character datatypes.
>
> TINYINT and ROWID deserve their own enhancement requests. I agree that
> an overall spec would be useful to make sure that we consistently
> handle the cross-release and client-server compatibility issues. I'll
> get around to this soon hopefully.
>
> Cheers,
> -Rick
>
> Satheesh Bandaram wrote:
>
>> Hi Rick,
>>
>> Pretty interesting... I hope you will find time to make a detailed
>> proposal available for community review.
>>
>> SQL standard, as you probably know, doesn't support TINYINT or ROWID.
>> TINYINT especially is not defined by DB2, Oracle... Also, how are you
>> planning on defining ROWID and what is its main purpose?
>>
>> Hope you will share your thoughts early...
>>
>> Satheesh
>>
>> Rick Hillegas wrote:
>>
>>
>>
>>> Hi Satheesh,
>>>
>>> Thanks for tracking these proposals. Here are the datatypes I want to
>>> add, re-enable, or extend in the 10.2 timeframe:
>>>
>>> BOOLEAN
>>> TINYINT
>>> NCHAR
>>> NVARCHAR
>>> LONGNVARCHAR
>>> NCLOB
>>> ROWID
>>> SQLXML
>>>
>>> Cheers,
>>> -Rick
>>>
>>> Satheesh Bandaram wrote:
>>>
>>>
>>>
>>>> I noticed several other new feature work being proposed and actively
>>>> being worked, possibly in time for next 10.2 release. Here is the
>>>> updated list I have so far. Let me know if I missed anything.
>>>>
>>>> 1. JDBC 4.0 Stub implementation
>>>> 2. Unary Plus/Minus.
>>>> 3. Code sharing proposal.
>>>> 4. Optimizer hints
>>>> 5. Timeout support in Derby client.
>>>> 6. Grant/Revoke in Derby
>>>> 7. I18 support and SQLStates for Derby client messages.
>>>> 8. Updatable, scrollable result sets
>>>> 9. New datatype(s) (Boolean)
>>>> 10. Making FOR UPDATE optional
>>>> 11. Online backup
>>>> 12. XML enhancements for XPATH/XQuery support
>>>> 13. setQueryTimeout for Derby client
>>>> 14. ALTER Table DROP COLUMN
>>>>
>>>> Satheesh
>>>>
>>>> Dag H. Wanvik wrote:
>>>>
>>>>
>>>>
>>>>>>>>>> "Satheesh" == Satheesh Bandaram <sa...@Sourcery.Org> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regarding "Long term" plans, as defined by DB project, I
>>>>>> wonder what other enhancements DerbyDev folks are working
>>>>>> on. I would like to know what else could be expected in the
>>>>>> next 6 months. Some of other development efforts I know
>>>>>> are:
>>>>>>
>>>>>> 1. JDBC 4.0 Stub implementation
>>>>>> 2. Unary Plus/Minus.
>>>>>> 3. Code sharing proposal.
>>>>>> 4. Optimizer hints
>>>>>> 5. Timeout support in Derby client.
>>>>>> 6. Grant/Revoke in Derby
>>>>>> 7. I18 support and SQLStates for Derby client messages.
>>>>>>
>>>>>>
>>>>>
>>>>> You can add:
>>>>> 8. Updatable, scrollable result sets
>>>>>
>>>>> We (Fernanda, Andreas and I) are making progress on making the
>>>>> scrollable (insensitive) result sets updatable, stay tuned.
>>>>>
>>>>> Dag
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Satheesh,
TINYINT, as you note, is not an ANSI datatype. It is, however, a JDBC
datatype and is supported by MySQL and SQL Server. Adding it would grow
our JDBC support and help close the feature gap with some significant
databases. I think those are compelling arguments. Fortunately, TINYINT
is already supported by Derby--it was only lightly disabled when the
non-DB2 datatypes were hidden. Re-enabling it should be easy.
ROWID is another JDBC type. to be added as part of the JDBC 4.0 effort.
It underlies the java.sql.RowId interface. Oracle calls these columns
ROWIDs and Postgres calls them OIDs. This type needs some specifying.
Enhancement requests 499 and 533 track the re-enabling of BOOLEAN and
national character datatypes.
TINYINT and ROWID deserve their own enhancement requests. I agree that
an overall spec would be useful to make sure that we consistently handle
the cross-release and client-server compatibility issues. I'll get
around to this soon hopefully.
Cheers,
-Rick
Satheesh Bandaram wrote:
>Hi Rick,
>
>Pretty interesting... I hope you will find time to make a detailed
>proposal available for community review.
>
>SQL standard, as you probably know, doesn't support TINYINT or ROWID.
>TINYINT especially is not defined by DB2, Oracle... Also, how are you
>planning on defining ROWID and what is its main purpose?
>
>Hope you will share your thoughts early...
>
>Satheesh
>
>Rick Hillegas wrote:
>
>
>
>>Hi Satheesh,
>>
>>Thanks for tracking these proposals. Here are the datatypes I want to
>>add, re-enable, or extend in the 10.2 timeframe:
>>
>>BOOLEAN
>>TINYINT
>>NCHAR
>>NVARCHAR
>>LONGNVARCHAR
>>NCLOB
>>ROWID
>>SQLXML
>>
>>Cheers,
>>-Rick
>>
>>Satheesh Bandaram wrote:
>>
>>
>>
>>>I noticed several other new feature work being proposed and actively
>>>being worked, possibly in time for next 10.2 release. Here is the
>>>updated list I have so far. Let me know if I missed anything.
>>>
>>> 1. JDBC 4.0 Stub implementation
>>> 2. Unary Plus/Minus.
>>> 3. Code sharing proposal.
>>> 4. Optimizer hints
>>> 5. Timeout support in Derby client.
>>> 6. Grant/Revoke in Derby
>>> 7. I18 support and SQLStates for Derby client messages.
>>> 8. Updatable, scrollable result sets
>>> 9. New datatype(s) (Boolean)
>>> 10. Making FOR UPDATE optional
>>> 11. Online backup
>>> 12. XML enhancements for XPATH/XQuery support
>>> 13. setQueryTimeout for Derby client
>>> 14. ALTER Table DROP COLUMN
>>>
>>>Satheesh
>>>
>>>Dag H. Wanvik wrote:
>>>
>>>
>>>
>>>>>>>>>"Satheesh" == Satheesh Bandaram <sa...@Sourcery.Org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Regarding "Long term" plans, as defined by DB project, I
>>>>>wonder what other enhancements DerbyDev folks are working
>>>>>on. I would like to know what else could be expected in the
>>>>>next 6 months. Some of other development efforts I know
>>>>>are:
>>>>>
>>>>>1. JDBC 4.0 Stub implementation
>>>>>2. Unary Plus/Minus.
>>>>>3. Code sharing proposal.
>>>>>4. Optimizer hints
>>>>>5. Timeout support in Derby client.
>>>>>6. Grant/Revoke in Derby
>>>>>7. I18 support and SQLStates for Derby client messages.
>>>>>
>>>>>
>>>>>
>>>>You can add:
>>>>8. Updatable, scrollable result sets
>>>>
>>>>We (Fernanda, Andreas and I) are making progress on making the
>>>>scrollable (insensitive) result sets updatable, stay tuned.
>>>>
>>>>Dag
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Hi Rick,
Pretty interesting... I hope you will find time to make a detailed
proposal available for community review.
SQL standard, as you probably know, doesn't support TINYINT or ROWID.
TINYINT especially is not defined by DB2, Oracle... Also, how are you
planning on defining ROWID and what is its main purpose?
Hope you will share your thoughts early...
Satheesh
Rick Hillegas wrote:
> Hi Satheesh,
>
> Thanks for tracking these proposals. Here are the datatypes I want to
> add, re-enable, or extend in the 10.2 timeframe:
>
> BOOLEAN
> TINYINT
> NCHAR
> NVARCHAR
> LONGNVARCHAR
> NCLOB
> ROWID
> SQLXML
>
> Cheers,
> -Rick
>
> Satheesh Bandaram wrote:
>
>> I noticed several other new feature work being proposed and actively
>> being worked, possibly in time for next 10.2 release. Here is the
>> updated list I have so far. Let me know if I missed anything.
>>
>> 1. JDBC 4.0 Stub implementation
>> 2. Unary Plus/Minus.
>> 3. Code sharing proposal.
>> 4. Optimizer hints
>> 5. Timeout support in Derby client.
>> 6. Grant/Revoke in Derby
>> 7. I18 support and SQLStates for Derby client messages.
>> 8. Updatable, scrollable result sets
>> 9. New datatype(s) (Boolean)
>> 10. Making FOR UPDATE optional
>> 11. Online backup
>> 12. XML enhancements for XPATH/XQuery support
>> 13. setQueryTimeout for Derby client
>> 14. ALTER Table DROP COLUMN
>>
>> Satheesh
>>
>> Dag H. Wanvik wrote:
>>
>>>>>>>> "Satheesh" == Satheesh Bandaram <sa...@Sourcery.Org> wrote:
>>>>>>>>
>>>>>>>
>>>
>>>
>>>
>>>> Regarding "Long term" plans, as defined by DB project, I
>>>> wonder what other enhancements DerbyDev folks are working
>>>> on. I would like to know what else could be expected in the
>>>> next 6 months. Some of other development efforts I know
>>>> are:
>>>>
>>>> 1. JDBC 4.0 Stub implementation
>>>> 2. Unary Plus/Minus.
>>>> 3. Code sharing proposal.
>>>> 4. Optimizer hints
>>>> 5. Timeout support in Derby client.
>>>> 6. Grant/Revoke in Derby
>>>> 7. I18 support and SQLStates for Derby client messages.
>>>>
>>>
>>>
>>> You can add:
>>> 8. Updatable, scrollable result sets
>>>
>>> We (Fernanda, Andreas and I) are making progress on making the
>>> scrollable (insensitive) result sets updatable, stay tuned.
>>>
>>> Dag
>>>
>>>
>>>
>>>
>>>
>
>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Army <qo...@sbcglobal.net>.
Rick Hillegas wrote:
> I like Lance's suggestion and would like to propose it as a general
> policy. I think that this will handle Army's XML work as well as the
> other new 10.2 datatypes:
>
> If you add a new datatype to a server release (e.g., BOOLEAN or XML),
> then you must specify the following:
Where would we specify these? In the code, in the documentation, in the
functional spec, somewhere else, all of the above? By specify do you mean for
informational/doc purposes, or are you referring to actual code in the
server/client that does this "specifying"?
> 1) A legacy datatype to which the new type maps when the server talks to
> old clients. The legacy type is some datatype in JDBC 2.0
> java.sql.Types. This is the type which old clients see in
> DatabaseMetaData and ResultSetMetaData.
Does "old client" here simply mean Derby clients with Derby versions earlier
than the server version (regardless of client-side jvm), or does it also mean
"old clients" in the sense that you defined it in one of your other posts, namely:
- The DB2JCC client
- The 10.1 client
- A 10.2 client running on jdk1.3 (JDBC 2), jdk1.4 (JDBC 3), or jdk1.5 (JDBC 3)
(assuming the appropriate Derby and jvm versions are substituted in)?
Army
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>>
>> Maybe replace 'you must' with 'you can'. If someone has the itch to add
>> a type for embedded only, then I don't think they should be forced to
>> make it work with old or new clients.
>>
>
> I'm concerned that if you can create a column, you ought to be able to
> poke values into it and then peek at them.
That's exactly it. "I'm concerned", that's your itch. :-)
Dan.
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>
>>I like Lance's suggestion and would like to propose it as a general
>>policy. I think that this will handle Army's XML work as well as the
>>other new 10.2 datatypes:
>>
>>If you add a new datatype to a server release (e.g., BOOLEAN or XML),
>>then you must specify the following:
>>
>>
>
>Maybe replace 'you must' with 'you can'. If someone has the itch to add
>a type for embedded only, then I don't think they should be forced to
>make it work with old or new clients.
>
>Also for something like XML datatype, is there any requirement to make
>it be available (in any form) with old clients? Is it not sufficient to
>say if you want to use the XML data type you must use the 10.2 client.
>If someone wants to do that work, that's fine, but I don't see it as a
>requiement.
>
>
I'm concerned that if you can create a column, you ought to be able to
poke values into it and then peek at them. In addition, some code has to
go into the network layer, if only to raise exceptions when new
datavalues try to leak across the wire. I suspect that detecting
incompatibilities is the hard part.
>
>
>>1) A legacy datatype to which the new type maps when the server talks to
>>old clients. The legacy type is some datatype in JDBC 2.0
>>java.sql.Types. This is the type which old clients see in
>>DatabaseMetaData and ResultSetMetaData.
>>
>>
>
>Can old clients that are running as JDBC 3.0 see types from JDBC 3.0?
>
>
I'm not sure I understand the question. Are you thinking about BOOLEAN
and TINYINT? The Derby network layer seems to tightly couple JDBC type
with transport format. Your question makes me think of another issue I
have not addressed: What happens if a 10.2 client running at JDBC 3.0
selects an XML value?
I am struggling to describe datatype behavior without a matrix of
release and vm levels, which would confuse product support. Here's
another attempt to summarize the behavior:
1) The new datatype has an associated legacy 2.0 datatype for use with
old clients and old JDBC levels.
2) The new datatype's "server level" is the Derby release which
introduces the datatype. Similarly, the new datatype's "JDBC level" is
the JDBC version which introduced the type.
3) To see the new datatype, the client must run at or above the
datatype's server and JDBC levels.
4) Otherwise, the client sees the legacy datatype.
I'm not sure that's simpler than a matrix, but there it is. :)
>Is this just for the network server, how about embedded, e.g. running
>Derby on JDK 1.3/1.4?
>
>
Thanks for raising this case. Let's keep it simple and apply the same
rules. Fortunately, in the embedded case the client runs at the server's
rev level. So it's just a question of JDBC level. So let's imagine a
10.2 embedded server running at JDBC 3.0. The customer creates BOOLEAN
columns and peeks/pokes them as BOOLEAN. The customer create SQLXML
columns but peeks/pokes them as CLOB.
>
>
>>2) A pair of ResultSet.get() and PreparedStatement.set() methods which
>>old clients can use to access the new datavalues. These must be get()
>>and set() methods which appear in JDBC 2.0 ResultSet and
>>PreparedStatement. They should be the get() and set() methods most
>>natural to the legacy datatype in (1). These methods determine how the
>>datavalues flow across DRDA.
>>
>>
>
>Just curious as to why specifying the getXXX and setXXX method is
>required, doesn't it follow from the legacy JDBC type specified? Or is
>there some deeper thought here I am missing? For example, in your
>example, with NCLOB can the client use setClob, setString etc?
>
>
Nothing deep, I'm just being pedantic. As you note, the mapping
determines the legacy dataype and datavalue and therefore the transport
format. The customer should be able to use any getXXX and setXXX method
that works for that transport format. We could leave this as an exercise
for the reader.
>Dan.
>
>
>
>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> I like Lance's suggestion and would like to propose it as a general
> policy. I think that this will handle Army's XML work as well as the
> other new 10.2 datatypes:
>
> If you add a new datatype to a server release (e.g., BOOLEAN or XML),
> then you must specify the following:
Maybe replace 'you must' with 'you can'. If someone has the itch to add
a type for embedded only, then I don't think they should be forced to
make it work with old or new clients.
Also for something like XML datatype, is there any requirement to make
it be available (in any form) with old clients? Is it not sufficient to
say if you want to use the XML data type you must use the 10.2 client.
If someone wants to do that work, that's fine, but I don't see it as a
requiement.
> 1) A legacy datatype to which the new type maps when the server talks to
> old clients. The legacy type is some datatype in JDBC 2.0
> java.sql.Types. This is the type which old clients see in
> DatabaseMetaData and ResultSetMetaData.
Can old clients that are running as JDBC 3.0 see types from JDBC 3.0?
Is this just for the network server, how about embedded, e.g. running
Derby on JDK 1.3/1.4?
> 2) A pair of ResultSet.get() and PreparedStatement.set() methods which
> old clients can use to access the new datavalues. These must be get()
> and set() methods which appear in JDBC 2.0 ResultSet and
> PreparedStatement. They should be the get() and set() methods most
> natural to the legacy datatype in (1). These methods determine how the
> datavalues flow across DRDA.
Just curious as to why specifying the getXXX and setXXX method is
required, doesn't it follow from the legacy JDBC type specified? Or is
there some deeper thought here I am missing? For example, in your
example, with NCLOB can the client use setClob, setString etc?
Dan.
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Rick Hillegas <Ri...@Sun.COM>.
I like Lance's suggestion and would like to propose it as a general
policy. I think that this will handle Army's XML work as well as the
other new 10.2 datatypes:
If you add a new datatype to a server release (e.g., BOOLEAN or XML),
then you must specify the following:
1) A legacy datatype to which the new type maps when the server talks to
old clients. The legacy type is some datatype in JDBC 2.0
java.sql.Types. This is the type which old clients see in
DatabaseMetaData and ResultSetMetaData.
2) A pair of ResultSet.get() and PreparedStatement.set() methods which
old clients can use to access the new datavalues. These must be get()
and set() methods which appear in JDBC 2.0 ResultSet and
PreparedStatement. They should be the get() and set() methods most
natural to the legacy datatype in (1). These methods determine how the
datavalues flow across DRDA.
I'm attaching a table which shows mappings for XML and the other new
10.2 datatypes. I have omitted ROWID right now because I don't
understand it yet.
Cheers,
-Rick
Lance J. Andersen wrote:
>
>
> Satheesh Bandaram wrote:
>
>>Hi Rick,
>>
>>Rick Hillegas wrote:
>>
>>
>>
>>>We will probably have to collaborate here. If you select an XML
>>>column, the ResultSetMetaData needs to say that the column is of type
>>>java.sql.SQLXML. This, at least, was the consensus of the community
>>>which prevented me from re-enabling the BOOLEAN datatype a couple
>>>months ago: Kathey and David pointed out that it was not OK for
>>>ResultSetMetaData to report a boolean column's type as SMALLINT.
>>>Similarly, it's not going to be OK for ResultSetMetaData to report the
>>>type of an XML column as java.sql.LONGVARCHAR.
>>>
>>>
>>
>>It doesn't seem right to expose a JDBC 4.0 type to a JDBC 3.0 client.
>>What good would that do, since JDBC 3.0 clients are probably written to
>>expect JDBC 3.0 functionality only? I wonder if we might even break GUIs
>>and other generic tools that expect 3.0 types only. Since we may be
>>close to enabling full JDBC 4.0 in the near term, why not expose only
>>JDBC 3.0 types to 3.0 clients? That is to expose XML type as a CLOB
>>under JDBC 3.0 and as SQLXML for a JDBC 4.0 client. This would expose a
>>new type to Derby server, XML, to JDBC by mapping it to it's closest
>>match. Remember the TINYINT discussion and Dan's point?
>>
>>
> A JDBC 3 driver should not return SQLXML as a type in ResultSetMetaData.
>
> I am not sure TINYINT is the same discussion though as JDBC has
> provided support for this since JDBC 1.0.x.
>
> A JDBC 3 driver should only return results defined in classes for the
> given version of JDBC and since JDBC 3 did not have SQLXML in
> java.sql.Types, you need to return a different value.
>
>>I don't remember what was discussed about this during the BOOLEAN
>>discussion... but if JDBC already supports a boolean type, that would
>>seem correct to map it to, rather than say SMALLINT.
>>
>>
> Correct, if the datatype is in Types.java and the backend datatype is
> also there, they should map to the same (unless there is something
> major league wrong with what the meaning of the type is on the backend)
>
> Regards
> Lance
>
>>Satheesh
>>
>>
>>
>>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Satheesh Bandaram wrote:
>Hi Rick,
>
>Rick Hillegas wrote:
>
>
>
>>We will probably have to collaborate here. If you select an XML
>>column, the ResultSetMetaData needs to say that the column is of type
>>java.sql.SQLXML. This, at least, was the consensus of the community
>>which prevented me from re-enabling the BOOLEAN datatype a couple
>>months ago: Kathey and David pointed out that it was not OK for
>>ResultSetMetaData to report a boolean column's type as SMALLINT.
>>Similarly, it's not going to be OK for ResultSetMetaData to report the
>>type of an XML column as java.sql.LONGVARCHAR.
>>
>>
>
>It doesn't seem right to expose a JDBC 4.0 type to a JDBC 3.0 client.
>What good would that do, since JDBC 3.0 clients are probably written to
>expect JDBC 3.0 functionality only? I wonder if we might even break GUIs
>and other generic tools that expect 3.0 types only. Since we may be
>close to enabling full JDBC 4.0 in the near term, why not expose only
>JDBC 3.0 types to 3.0 clients? That is to expose XML type as a CLOB
>under JDBC 3.0 and as SQLXML for a JDBC 4.0 client. This would expose a
>new type to Derby server, XML, to JDBC by mapping it to it's closest
>match. Remember the TINYINT discussion and Dan's point?
>
>
A JDBC 3 driver should not return SQLXML as a type in ResultSetMetaData.
I am not sure TINYINT is the same discussion though as JDBC has provided
support for this since JDBC 1.0.x.
A JDBC 3 driver should only return results defined in classes for the
given version of JDBC and since JDBC 3 did not have SQLXML in
java.sql.Types, you need to return a different value.
>I don't remember what was discussed about this during the BOOLEAN
>discussion... but if JDBC already supports a boolean type, that would
>seem correct to map it to, rather than say SMALLINT.
>
>
Correct, if the datatype is in Types.java and the backend datatype is
also there, they should map to the same (unless there is something major
league wrong with what the meaning of the type is on the backend)
Regards
Lance
>Satheesh
>
>
>
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Hi Rick,
Rick Hillegas wrote:
>
> We will probably have to collaborate here. If you select an XML
> column, the ResultSetMetaData needs to say that the column is of type
> java.sql.SQLXML. This, at least, was the consensus of the community
> which prevented me from re-enabling the BOOLEAN datatype a couple
> months ago: Kathey and David pointed out that it was not OK for
> ResultSetMetaData to report a boolean column's type as SMALLINT.
> Similarly, it's not going to be OK for ResultSetMetaData to report the
> type of an XML column as java.sql.LONGVARCHAR.
It doesn't seem right to expose a JDBC 4.0 type to a JDBC 3.0 client.
What good would that do, since JDBC 3.0 clients are probably written to
expect JDBC 3.0 functionality only? I wonder if we might even break GUIs
and other generic tools that expect 3.0 types only. Since we may be
close to enabling full JDBC 4.0 in the near term, why not expose only
JDBC 3.0 types to 3.0 clients? That is to expose XML type as a CLOB
under JDBC 3.0 and as SQLXML for a JDBC 4.0 client. This would expose a
new type to Derby server, XML, to JDBC by mapping it to it's closest
match. Remember the TINYINT discussion and Dan's point?
I don't remember what was discussed about this during the BOOLEAN
discussion... but if JDBC already supports a boolean type, that would
seem correct to map it to, rather than say SMALLINT.
Satheesh
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Army,
Some additional comments follow. Cheers-Rick
Army wrote:
...
>
> That said, I spent some time looking at this more and I tend to agree
> with you about moving the logic to the network layer: it does some
> cleaner to do it that way, as that will allow the server to recognize
> the XML type and behave accordingly (with compile-time "coercion", the
> server wouldn't be able to tell the difference between a legitimate
> CLOB value and a CLOB value that was the result of implicit
> serialization in the engine). I'll try to alter my approach as you
> suggest and see what happens.
Great. Thanks.
>
> As for your other suggestions regarding JDBC 4.0 support for XML and
> how it should work with different server/client combinations, I think
> your post to DERBY-688 is a good starting point for that discussion.
> However, I wonder if much of what you've posted there is beyond the
> scope of what I'm looking to do for DERBY-688? Would it make more
> sense for you to create a new Jira entry specifically for the JDBC 4.0
> XML support and move the discussion there?
We will probably have to collaborate here. If you select an XML column,
the ResultSetMetaData needs to say that the column is of type
java.sql.SQLXML. This, at least, was the consensus of the community
which prevented me from re-enabling the BOOLEAN datatype a couple months
ago: Kathey and David pointed out that it was not OK for
ResultSetMetaData to report a boolean column's type as SMALLINT.
Similarly, it's not going to be OK for ResultSetMetaData to report the
type of an XML column as java.sql.LONGVARCHAR.
>
> Note that, while I do want to look at moving the implicit
> serialization/parsing to the network layer as you suggest, I do _not_
> plan to explicitly code up the various guidelines that you outlined in
> your post--as I said, I think that's beyond the scope of DERBY-688.
> My hope is to avoid making changes in DERBY-688 that will interfere
> with or otherwise hinder the JDBC 4.0 plans/guidelines that you have
> described, but I will not be implementing those 4.0 plans as part of
> the DERBY-688 work.
Fortunately, most of this work can be deferred to the JDBC 4.0 project.
However, as I said above, we are going to need to address the type
exposed by ResultSetMetaData.
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Army <qo...@sbcglobal.net>.
Hi Rick,
Thanks for your feedback. My comments below.
Rick Hillegas (JIRA) wrote:
> When I initially read your spec, I came away with the notion
> that the implicit coercion would happen in the compiler. But
> based on the paragraph above, it sounds like you intend to
> put the coercion in the network layer. That's where I
> think it belongs, too.
Well actually, your inital notion was correct: I was indeed planning to do the
"coercion" (i.e. implicit XMLSERIALIZE/XMLPARSE) at compile time. That seemed
like the simplest place to do it since all the code would be in a single place
within the Derby engine and no changes would be required in the server code.
That said, I spent some time looking at this more and I tend to agree with you
about moving the logic to the network layer: it does some cleaner to do it that
way, as that will allow the server to recognize the XML type and behave
accordingly (with compile-time "coercion", the server wouldn't be able to tell
the difference between a legitimate CLOB value and a CLOB value that was the
result of implicit serialization in the engine). I'll try to alter my approach
as you suggest and see what happens.
As for your other suggestions regarding JDBC 4.0 support for XML and how it
should work with different server/client combinations, I think your post to
DERBY-688 is a good starting point for that discussion. However, I wonder if
much of what you've posted there is beyond the scope of what I'm looking to do
for DERBY-688? Would it make more sense for you to create a new Jira entry
specifically for the JDBC 4.0 XML support and move the discussion there?
Note that, while I do want to look at moving the implicit serialization/parsing
to the network layer as you suggest, I do _not_ plan to explicitly code up the
various guidelines that you outlined in your post--as I said, I think that's
beyond the scope of DERBY-688. My hope is to avoid making changes in DERBY-688
that will interfere with or otherwise hinder the JDBC 4.0 plans/guidelines that
you have described, but I will not be implementing those 4.0 plans as part of
the DERBY-688 work.
Thanks again for taking the time to review the spec. I appreciate your comments.
Army
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Army,
Some more comments follow. Cheers-Rick
...
>
> Ah, okay, I had a feeling that JDBC 4.0 was where you were headed :)
> I agree there is a need for this, and I'm glad you're looking at
> getting the 4.0 machinery in place. Note that, in the meantime, I am
> working on a pre-JDBC 4.0 solution to this issue: in the document I
> posted to DERBY-688 yesterday, one of the things I mention, under the
> "usability" section, is implicit serialization/parsing at the JDBC
> level, which will allow both of the above statements to compile.
> Then, the user can use 'getString' in the first case to get the
> result, and 'setString' in the second to bind to an XML value. But as
> I said, that's more of a solution for pre-JDBC 4.0 JVMs. To have the
> "setSQLXML" and "getSQLXML" functionality that you mention is
> certainly a great longer term goal for JDBC 4.0 support, as that gives
> the user more control over an XML value.
Sounds like we are on the same page then. When I initially read your
spec, I came away with the notion that the implicit coercion would
happen in the compiler. But based on the paragraph above, it sounds like
you intend to put the coercion in the network layer. That's where I
think it belongs, too.
>
>> There will continue to be only one XML datatype--the one you have
>> already built a foundation for. It is just going to be more capable.
>
>
> Great, this is what I was hoping. So in your original email, when you
> list "SQLXML" as a new type, that's the JDBC name of the type, not the
> SQL name, correct? I.e. there will _not_ be support for things like:
>
> ij> create table xt (x sqlxml);
>
> only
>
> ij> create table xt (x xml);
Right.
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Army <qo...@sbcglobal.net>.
Rick Hillegas wrote:
> I would like to hook the XML type up to the network layer and the JDBC
> 4.0 machinery.Currently, you cannot select an XML column and return it
> to the client. Nor can you insert directly into an XML column. I would
> like to make the compiler accept the following statements:
>
> select xmlColumn from fooTable;
> insert into fooTable ( xmlColumn ) values ( ? );
>
> and I would like to implement the following jdbc methods:
>
> PreparedStatement.setSQLXML()
> ResultSet.getSQLXML()
Ah, okay, I had a feeling that JDBC 4.0 was where you were headed :) I agree
there is a need for this, and I'm glad you're looking at getting the 4.0
machinery in place. Note that, in the meantime, I am working on a pre-JDBC 4.0
solution to this issue: in the document I posted to DERBY-688 yesterday, one of
the things I mention, under the "usability" section, is implicit
serialization/parsing at the JDBC level, which will allow both of the above
statements to compile. Then, the user can use 'getString' in the first case to
get the result, and 'setString' in the second to bind to an XML value. But as I
said, that's more of a solution for pre-JDBC 4.0 JVMs. To have the "setSQLXML"
and "getSQLXML" functionality that you mention is certainly a great longer term
goal for JDBC 4.0 support, as that gives the user more control over an XML value.
> There will continue to be only one XML datatype--the one you have
> already built a foundation for. It is just going to be more capable.
Great, this is what I was hoping. So in your original email, when you list
"SQLXML" as a new type, that's the JDBC name of the type, not the SQL name,
correct? I.e. there will _not_ be support for things like:
ij> create table xt (x sqlxml);
only
ij> create table xt (x xml);
If this is correct, then I _think_ this will be the first type in Derby where
the JDBC type name and the SQL type name differ (don't hold me to that--I only
looked briefly). That doesn't necessarily mean anything, it's just something I
find interesting.
> If you want to help out with any of these tasks, I will be delighted!
I will be happy to help where I can. Right now, my "itch" is the work I'm doing
for DERBY-688, but ultimately I think we're both heading toward the same goal,
so I trust there will be opportunities for us (and anyone else interested, for
that matter) to help each other out along the way.
Thanks for the info,
Army
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Army,
I would like to hook the XML type up to the network layer and the JDBC
4.0 machinery. Currently, you cannot select an XML column and return it
to the client. Nor can you insert directly into an XML column. I would
like to make the compiler accept the following statements:
select xmlColumn from fooTable;
insert into fooTable ( xmlColumn ) values ( ? );
and I would like to implement the following jdbc methods:
PreparedStatement.setSQLXML()
ResultSet.getSQLXML()
There will continue to be only one XML datatype--the one you have
already built a foundation for. It is just going to be more capable. If
you want to help out with any of these tasks, I will be delighted!
Cheers,
-Rick
Army wrote:
> Rick Hillegas wrote:
>
>> Here are the datatypes I want to add, re-enable, or extend in the
>> 10.2 timeframe:
>>
> [ snip ]
>
>>
>> SQLXML
>>
>
> How would this (the "SQLXML" type) differ from the existing "XML" type
> available as of 10.1.1 (DERBY-334)?
>
> Army
>
Re: New features for next release .... (Was: Grant and Revoke ...
DERBY-464...)
Posted by Army <qo...@sbcglobal.net>.
Rick Hillegas wrote:
> Here are the datatypes I want to add, re-enable, or extend in the
> 10.2 timeframe:
>
[ snip ]
>
> SQLXML
>
How would this (the "SQLXML" type) differ from the existing "XML" type available
as of 10.1.1 (DERBY-334)?
Army