On 23-07-15 18:45, Jody Garnett wrote: > > I implemented replacement watchers as part of the migration? Are they > not working for you ... > And that code should still work, the directory will get unpacked - but > it is not any kind of fun.
If the changes are picked up and written to the db properly.. I am having some issues with watching actually. Can we talk about this on skype or IRC ? Are you online today? Either way, you have to admit it is not the ideal way of doing this, writing data to the file system and secretly picking this up in another thread and writing it to the database. It's also very hard to test, at this moment the resourcestore test assume that changes happen immediately. I found that I had to put in a delay of 20 seconds (!) for the test to work on the jdbcresourcestore, but there is no guarantee that this will work always and everywhere within that time frame. We cannot possibly know when the other thread has finished updating the database, can we? How would you suggest testing it? > You statement is a bit circular. Yes you can use dir() to create the > folder on the file system if needed (just like you can use file() to > create a file). Is there anything else you need that is not provided? > > Like who cares if the directory is created or not, as long as it > behaves the same... It is up to your store implementation if you want > an internal representation of a directory or not. I think you can > create it in a lazy fashion as needed while respecting the api ... > > Is directory creation or not just an internal detail? Do we agree on this: the file() and dir() methods are only for backwards compatibility and should be discouraged (deprecated in my opinion). People should be use in() and out() instead, right? If you want to really use the resource system, and NOT the file system, there is no way of making sure a directory exists in the resource store (DB). > To list contents, rename, etc... Indeed, but we can only do all of these things if the directory already exists. And we cannot easily force it to exist if we we need it to exist (see my example code). Basically, it is not possible to create an empty directory unless you create a dummy file and then delete it. > Okay I see your concern. If you list() an undefined resource you get > an empty list .. can you use a UNDEFINED resource and trust it to > behave as a directory for your code? I thought list() would throw an exception, but it actually returns null. I guess you have a point there, just leaving it as undefined would work. It does require us to do a null check, but okay. Some operation like rename might also require us to check if it actually exists, while if we knew for sure it did we didn't have to worry. It seems like it would add more ifs to the code, often needing to verify whether it is actually a directory yet or not. Also , if the existence of directories is to an implementation detail hidden from the users, why is it possible to delete (but not to create an empty) directory? > This would help if you can hunt down an example from the codebase :) > Especially if you want to replace FileWatch ... Anything that calls findOrCreateDirectory(). Not sure what you mean with replacing FileWatch ? > I am not close enough to the code to know specifically what you are > talking about. I probably didn't explain it properly, but it's not really necessary to know the code. Basically, currently the jdbcresource holds a OID of the resource that is uses to query the database. But if something deletes and replaces the resource located at that same path with new data, a resource object still holding the old OID will not be able to know this. While you would expect it to, since the filesystemresource works this way. Regards Niels ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
