[
https://issues.apache.org/jira/browse/DERBY-6912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554120#comment-15554120
]
Trejkaz commented on DERBY-6912:
--------------------------------
Actually, on trying to implement StorageRandomAccessFile on top of Path, there
are a lot of behaviours of the other one which are difficult to implement on
NIO2.
For instance, DirRandomAccessFile#seek(long) works even if the thread is
interrupted, but FileChannel#setPosition throws an exception if the thread is
interrupted. Therefore, to implement seek(long) correctly, I have avoided using
the actual file pointer and just keep a variable.
This would be fine, except I have now discovered that DirRandomAccessFile#read
also works when the thread is interrupted, but of course FileChannel#read
fails. So to implement that one, I would have to ignore the exception, clear
the interrupt flag, read the data again, then reset the interrupt flag at the
end. It seems doable but it has stopped being something fairly easy to drop in.
> 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
(v6.3.4#6332)
