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

Reply via email to