Hi Jody,
On 23-07-15 17:53, Jody Garnett wrote:
> Have a look at the examples I linked to. We need a second QA pass
> through the codebase to remove references to files (and deprecate
> methods like getOrCreateDirectory). For the first pass I just
> implemented them all in terms of Resource - but any code that asks for
> a file will get one (unpacking the blob from the resource store if
> needed).
I'm currently trying to implement that changes to the cached files are
noticed by a file-watcher and then written to the database, it's
technically possible but that seems quite dodgy and error prone to me.
It is fine as a fall-back mechanism for backwards compatibility and it
allows us to gradually change all the modules rather than all at once,
but I would strongly discourage it and deprecate those methods in the API.
Right now we actually have lots of code that just asks one time for
one directory in the datadir and then uses the file system from there
onwards....
Either way, I still find it strange in the API that we can have a
resource that represent a directory, but no way to create such a thing,
unless by creating a file inside it. This was my concern, and I haven't
been 100% convinced it makes sense.
You can do:
Resource fileRes = store.get("/some/path/to/a/file");
fileRes.out() //creates the file and the directories "some", "path",
"to", and "a" if necessary
Okay, that is convenient. But what about this:
Resource dirRes = fileRes.getParent();
Type type = dirRes.getType(); //returns dirRes.getDirectory()
Cool. But imagine now doing this:
Resource dirRes = store.get("/some/path/to/a/dir");
//there is no way to simply create this path as a directory in the store!
//note the dirRes.dir() always creates a directory on the _file system_
(caching it if necessary), a method we wish to deprecate!
Yes, of course, technically we could modify all the code to create
configuration files directly by their full path, and ignore directories
altogether. But then why is there such a thing as a Resource of type
directory?
For the sake of convenience you could want to work with a directory
resource to query and modify its children. For example :
class MyClass {
Resource myDir;
void myMethod() {
... //I need to do something depending on all the files inside our
directory
List<Resource> children = myDir.list() ...
...
}
MyClass() {
//initialize our config dir
myDir = store.get("/my_config_dir");
if (myDir.getType() == Type.UNDEFINED) {
//what now???
//there is no way to create this directory unless we create a
file inside it. but what if we don't need to yet at this stage?
//create a dummy file == ugly
}
}
}
See how it can be inconvenient that there is no explicit directory
creating mechanism?
>
> We can wait to hear from kevin, but I am not sure he is too concerned
> about how JDBCResourceStore takes shape. We went over a couple
> different designs (including placeholder entries for directories, so
> that resources could link to their "parent").
That seems to be the design indeed.
>
> What is you idea with Paths? Use a like filter to shortlist directory
> contents for Resource.list() ?
>
The design of the database does not need to be changed necessarily, but
definitely the design of the code. The resource object needs to hold the
path, not the ID. Otherwise, it will not be possible to hold use a
resource object for longer than a single method, and even then it is not
concurrency safe.
However, the efficiency of the database design might indeed be
questioned if we change the design of the code. In this design each
method would need find the record by recursively looping through the
path to find the resource. Is that so different from how files query the
file system though? I'm not sure. Advise regarding this question is welcome.
Regards
Niels
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
