On 29-08-17 10:22, Andrea Aime wrote:
This seems promising. NetCDF wise, the worry I have is that these
files are sprinkled around on the file system,
sidecars to the netcdf files themselves. Wondering if the removal and
rebuild could be automated?
Yeah, I was suggesting that could be easier than trying to fix the
exception. I don't see why not.
The other issue is that the upgrade will make it impossible to move
back, while this is unavoidable, it needs to be
well advertised. And it will cause pain for a year long for developers
jumping across branches (e.g., everybody
working in the GeoServer stable/maintenance branches).
I'm afraid it's a bridge we'll have to cross sooner or later... hum...
thinking out loud, would it make sense to create parallel databases,
old version and new version, with a different name? I guess the pain
is that this would require point by point changes in the code...
The upgrade does retain a backup of the old db, renaming it with an
additional extension. However, since the new db also has a new
extension, in theory I think the old version could just be left alone
and not renamed. Of course, the old and new version would then branch
off. It's annoying though that the upgrade is done by this JAR file that
seems hard or impossible for us to manipulate, neither through code nor
API possibilities.
Regards
Niels
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel