db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein Grovlen - Sun Norway <Oystein.Grov...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2247) provide set methods for blob in embeded driver
Date Thu, 18 Jan 2007 14:03:01 GMT
Daniel John Debrunner (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465625
> Daniel John Debrunner commented on DERBY-2247:
> ----------------------------------------------
>>> Why use the system temp folder and not the database's? The database's temp folder
will be cleaned up on re-boot.
>>> Could a existing store file be used so that encrpytion support would already
be there?
>> I was planning to use database tmp directory and one of the patch in the parent issue
uses database tmp directory and StoreFactory but lattered in the disscussion it was concluded
that the store api and tmp file system are not supposed to be used for creating random files
which are not part of database.
> I thought that discussion was about using store code in the network client., whereas
this is about using the code in embedded. With embedded the code is there and will by definition
already have the correct security permissions set up. 

The discussion on this can be found here:

I think Anurag's patch follows what was suggested in that discussion. 
Some excerpts from that discussion:

Mike Matrigali wrote:
 > This is an unexpected usage, this was never designed for that purpose.
 > It was originally designed as a module only to be used underneath the
 > store module.  The purpose was to allow alternate implementations of
 > the underlying filesystem.
 > I wonder why straight java i/o stream interfaces were not used?  Is
 > there anything being provided by the StorageFactory that a direct
 > use of java io does not easily provide?

Daniel John Debrunner wrote:
 > I think this is also true for embedded, using the
 > java.io.File.createTempFile() is the cleanest solution.

 > The StorageFactory is there to allow the database store to handle
 > different file types (jar, classpath, java i/o) and there is a
 > demonstrated need for this. Thus the database store consistently uses
 > the StorageFactory interfaces to access files and directories.  The
 > database store also needs temporary files and it needs them to be
 > handled using the same api's as the perisisent files. Thus
 > StorageFactory has a getTempDir() method, it's purpose in life is to
 > bring temp files into the world of the database store, not a general
 > purpose mechanism.


View raw message