We should also make the return value consistent. The return value was chosen for consistency with File.delete(). Much like making Resource method compatible with File, the return value made it easier to migrate code that made direct use of File.
> > Then ResourceStore.remove will have to change. And Files.delete as well (?) Sensible, would treat the inconsistency as a bug. Our intention was to make transition from File easier. > A question about resource.delete() being much more efficient to implement, >> are you checking (and acquiring) all the resource locks before deleting? >> > > Hmmm. That is a good point. But FileSystemResource.delete doesn't acquire > a lock. Is that normal? > Either way, we can get the locks recursively first. Best to keep sql > queries as efficient as possible. Okay, so lets go ahead with the proposal then. > With respect to creating a directory - I want to avoid putting developers >> in the situation where the API is forcing them to create a directory using >> boilerplate code prior creating files. Your earlier example showed >> directory creation as a placeholder (almost like a sentinel file) so I was >> not quite sure if it was a poor example or if you had an actual use case. >> >> Don't worry about this for now. Only reason to think about it is we could cover it in the same proposal. > My main concern is that we stop using Files wherever possible, also in > many cases where getOrCreateDirectory is used. But as we concluded, we may > as well just "get" the directory, and it will be created automatically when > create the first child. The only thing I'd consider is return an empty list > instead of a "null" for a non-existing directory to make the use of > directories easier that way. > Fair enough, yeah I like it, add it to the proposal.
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
