db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6912) Allow loading a database from a Path instead of a String file path
Date Thu, 29 Sep 2016 23:56:20 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15534457#comment-15534457

Rick Hillegas commented on DERBY-6912:

I'm afraid that I'm not understanding the issue. Does DataSource.setDatabaseName(path.toString())
not do the right thing?

> Allow loading a database from a Path instead of a String file path
> ------------------------------------------------------------------
>                 Key: DERBY-6912
>                 URL: https://issues.apache.org/jira/browse/DERBY-6912
>             Project: Derby
>          Issue Type: Improvement
>            Reporter: Trejkaz
> Java 7 added the new filesystem abstraction (Path) API.
> Our data is made up of a collection of multiple other databases. Other components of
our data, such as Lucene, already use the new Path API in the current released versions, so
it's now only Derby holding us up.
> I can make an alternative DirStorageFactory7, DirFile7, DirRandomAccessFile7 which all
use Path to do their work, instead of File. This turns out to be fairly easy, in fact.
> The blocker is currently that Derby currently forces us to provide the path to the database
as a string. This comes down to EmbeddedDataSourceInterface forcing me to pass a string for
pretty much everything. For instance, the database "name" usually becomes the file path, but
that's a string.
> {code}
>     void setDatabaseName(String name);
>     String getDatabaseName();
> {code}
> Even if I wanted to work around it by making a custom protocol, ignoring the name and
then using the connection attributes, the connection attributes were done as a string as well:
> {code}
>     void setConnectionAttributes(String attributes);
>     String getConnectionAttributes();
> {code}
> It would have been nice if this were a Map so that I could put other objects inside it.
> As far as other workarounds go, I can't extend EmbedPooledConnection, so I can't usefully
extend InternalDriver, so I can't usefully extend EmbeddedConnectionPoolDataSource myself.
If there is any other possibility which I have missed, I'd be interested to know.
> Really what I would like is a way to pass the Path directly to EmbeddedConnectionPoolDataSource.

This message was sent by Atlassian JIRA

View raw message