Support Standard DataSource Properties in JdbcDataSource

[GoogleCodeExporter]

Support Standard DataSource Properties in JdbcDataSource

This change adds support for many of the Standard DataSource Properties 
described in 
http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/datasource.html

The guide recommends that all DataSource implementations provide the
description property, and I intended to simply add that.  However,
most of the other properties, serverName, portNumber, databaseName, etc;
directly mapped to components of the URL used by JdbcDataSource.
I added these properties, exposed getters and setters, and construct
a URL from the components if the standard properties were specified,
rather a URL.

The implementation already supported the 'user' and 'password' 
Standard DataSource Properties.

I added support for the 'description', 'networkProtocol', 'serverName',
'portNumber', and 'databaseName' properties.

I also added non-standard properties 'zipName' which corresponds
to the ZIP file name used in 'jdbc:h2:zip:' URLs, and 'settings',
which corresponds to the additional settings that may be appended
to a URL (like ';CIPHER=XTEA;FILE_LOCK=SOCKET').

I did not add support the standard properties 'dataSourceName' and
'roleName', as I found no obviouse H2 equivalents.

Change List:
---------
M  h2/src/main/org/h2/jdbcx/JdbcDataSource.java
M  h2/src/main/org/h2/jdbcx/JdbcDataSourceFactory.java
M  h2/src/test/org/h2/test/jdbcx/TestDataSource.java

Code Review is available at http://codereview.appspot.com/244043

Original issue reported on code.google.com by Brett.Mi...@gmail.com on 7 Mar 2010 at 11:14

[GoogleCodeExporter]

Thanks for the patch!

description: I will add that.

For all the other properties: I think it would be very confusing, because H2 is 
not a
client/server database like Oracle.

databaseName: what if there is no name (unnamed in-memory databases)?

networkProtocol: mem: is not a network protocol. zip: is not one. Also, I don't 
want
to duplicate source code.

portNumber and serverName: what would it mean for embedded or in-memory 
databases?

Original comment by thomas.t...@gmail.com on 8 Mar 2010 at 5:43

[GoogleCodeExporter]

I encourage you to look at JdbcDataSource.makeURL()

> databaseName: what if there is no name (unnamed in-memory databases)?
The code makes the assumption that only in-memory databases are allowed to be 
unnamed.

> networkProtocol: mem: is not a network protocol. zip: is not one. Also, I 
don't want
to duplicate source code.
I generalized this property as "access protocol".  Granted, only 'tcp', 'ssl', 
and possibly 'gae' could be 
considered true network protocols.

> portNumber and serverName: what would it mean for embedded or in-memory 
databases?
Obviously serverName and PortNumber mean nothing in those circumstances.  I 
could throw 
IllegalStateException (or IllegalArgumentException) in that case.    

The goal of the enhancement was to allow the product to work better with 
administrative tools, 
SpringFramework bean properties, and such.  It doesn't preclude the 
administrator from knowing what they 
are doing.

Although our product will ship with H2, it will allow the customer to store the 
data in their own corporate 
datbase (typically Oracle or SQL Server).  The part I am working on simply gets 
a DataSource object - it 
doesn't know if it is a H2, Oracle, or SQL Server implementation.  I was hoping 
to get a bit more commonality 
in the interfaces.

Original comment by Brett.Mi...@gmail.com on 8 Mar 2010 at 6:40

[GoogleCodeExporter]

One problem is that makeURL doesn't support the pluggable file system. It 
duplicates
logic that belongs elsewhere. gae is a file system prefix, not a network 
protocol
(but I know what you mean).

> work better with administrative tools
> more commonality in the interfaces.

I understand. What about:

'networkProtocol': ssl, tcp, or null (meaning not networked)
'serverName': only if ssl or tcp (in this case not optional)
'portNumber': only if ssl or tcp (optional)
'databaseName': could be the file system url (gae:, mem:, file:,...)

Original comment by thomas.t...@gmail.com on 8 Mar 2010 at 7:22

[GoogleCodeExporter]

I am actually thinking this might be more appropriate as an Adapter that wraps 
JdbcDataSource on my side.  
My goal with putting it in JdbcDataSource was to apply a "standards properties 
view" over the information 
needed by JdbcDataSource when opening a connection.  However, the code is not 
that elegant and the 
impedance mis-match seems too high.

I recommend implementing the description property, the only property I really 
needed for my implementation 
(logging the jdbc configuration).  I liked my implementation that called 
toString() if the description had not 
been set externally, as the URL and username are just the type of info I would 
want in the logs.

Original comment by Brett.Mi...@gmail.com on 8 Mar 2010 at 5:54

[GoogleCodeExporter]

> I recommend implementing the description property

Sure, I will do that.

> Although our product will ship with H2

Could you tell me what this product is?

Original comment by thomas.t...@gmail.com on 8 Mar 2010 at 6:10

• Changed state: Accepted

[GoogleCodeExporter]

Implemented in version 1.2.132.

Original comment by thomas.t...@gmail.com on 21 Mar 2010 at 3:12

• Changed state: Fixed