Luigi Lauro wrote:
[lots of interesting stuff snipped]
Some answers below (mainly from memory), I didn't look into the code
much to see exact answers ...
Ok, now with the questions/doubts
A) StorageFactory.shutdown() - should a proper implementation delete the
'temporary' files if they are made persistent? I'm current planning to
implement temp files as standard storage entities, just 'tagged' with
PersistenceService.TEMPORARY, but since this tag does nothing
automatically, I will have to manually delete temporary entities at
startup/shutdown I think. Another approach would be to have the temp
files in memory, and do not keep them in the persistence storage: this
would save size/number of files and would make this unnecessary
I think removal of the temp files happens above the Storagefactory,
but it would also be ok for the Storagefactory to remove them on
shutdown. Adding comments to the javadoc for StorageFactory would help
here, e.g. temp files need not survive shutdown.
Just looked at the code and that comment already exists :-)
StorageFactory.getTempDir().
B) StorageFactory.init() - Let me see If i Got this right.
Home is directory of derby home (where all database are stored), but can
be ignored.
DatabaseName is subdir in home for the given database.
TempDirName is home for temp files (can temporary files be created also
outside of it, like in database directory? Is this possible?)
UniqueName is database specific subdirectory inside tempDirName.
Home shouldn't be created but provided (though in my case I have to
create it since the user can't).
DatabaseName can be null when you are using the StorageFactory just to
access the database directories (this will happen with my factory as
well?), but if its not I have to create home/databaseName.
TempDirName can be null and a default should be used, and the directory
created, but ONLY if uniqueName is not null. If uniqueName is null, then
no temp dir is available and from what I can guess it means Derby won't
use ANY TEMPORARY FILE AT ALL. Right?
Derby will create temp files in the database location. tempDirName (I
think) is for when the database StorageFactory is read-only (e.g.
database in a jar file) thus temp files need to be elsewhere.
Also, please use better names next time. IMHO home, databaseHome, temp,
databaseTemp would have been a wiser choice, more easily understood by
non-derbiers. Anyway.
home is not specific to a single database, thus databaseHome may not be
the correct term, it's really systemHome, as it comes from the property
derby.system.home.
Same for temp, it's a top-level folder that can contain temp files for
many databases.
Feel free to submit a patch with better names for parameters (that won't
change the api) and/or improved comments.
C) StorageFactory.newStorageFile(String path) - should this method also
create a temporary file, if the given path is under the temp dir? This
isn't clear IMHO: if they hand me a tempDir path, do I have to just wrap
it in a StorageFile, or Do I also have to create a temporary file with a
unique name and return it? I Really haven't clear all the
newStorageFile/createTemporaryFile methods, and even reading the
javadocs and looking at BaseStorageFactory, I still feel puzzled.
Can someone help me understand this? I'd love that :)
I'll try to find time to add some understanding ...
In this environment can you use File.createTempFile()?
D) This is hard to explain, but I will try my best. Since the
PersistenceService API only gives me a 'name' metadata for a given
storage entity, and I prefer not to save metadata inside the file
contents itself (this would make things harder to implement), I was
asking myself what metadata regarding the file do I have to keep.
Surely, first of all, I would need to tell if a storage entity it's
temporary or not. If temp files gets created ONLY under the tempDir,
this means I could use the name/path itself to tell this. But I'm still
wondering if derby creates temporary files also outside tempDir or not.
I think and hope not.
Also, I surely have to tell if a given storage entity it's a directory
or a file. I could tell them by the name/path as well (if they end with
SEPARATOR, they are dirs, if they don't, they are files), but this would
work ONLY if derby doesn't craft itself alone paths for
directories/files by parsing the path instead of using the
StorageFactory/StorageFile methods. If derby does, then derby could
produce a directory URL without the trailing separator, which will mess
things up.
Another approach would be to use the use a zero maximum length as
directory tag. A directory would have a zero length (and this is good
also, since I'll create directories storage entities just as a
placeholder, to tell if a directory was created or not), a file would
have a default 1024/whatever maximum length at start (remember that this
can be easily grow when needed, when I write to the entity).
Again, there is also a readonly bit on the files. Do I have to persist
this as well? It would be a problem if I 'lose' this information and
don't persist this? Also: are there any other file metadata bits which
I'm forgetting and that I should save in the persistent storage?
I think that is set only by the storage factory, i.e. it is telling
derby if this is a read-only database or not.
Thanks again for your help, If I get some answers to shed some lights
onto my doubts, I will fix a couple of things in the next few hours and
post an 'alpha' JNLPStorageFactory/StorageFile patch in the jira issue.
Also, since working on it I've found out there are SEVERAL similarities
between JNLP storage and an hypothetical memory storage using a simple
Map<Path, File>, I'm implementing things around an abstract base class
which delegates to the extending implementation classes only a couple of
CRUD methods (create/delete/rename/etc...) and build all the
StorageFactory/StorageFile logic on top of these.
This will mean I can probably get done a working MemoryStorageFactory
along with the JNLP one, since doing the former would be only a 5% work
more than doing my own JNLP storage, as I'm currently planning to do
things.
Cool.
Also, I think this could potentially lead to a massive
StorageFactory/StorageFile redesign for easier storage implementations,
or to some higher-level abstract class wrappers around the present
StorageFactory/StorageFile interfaces, such as the one I'm doing, that
depends only on a FEW storage methods, instead of the 30+ methods one
presently needs to implement to get a Storage working. Of course, this
is something I can't really tell if this is something needed and good
for real or not, given my very basic derby internal knowledge.
Sounds interesting.
Dan.
