On 12-08-15 17:35, Jody Garnett wrote: > > 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 (?) > > 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. > > 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. 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. Cheers Niels ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
