Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Nils Hoffmann wrote:
Hi Jon and also to the list, Jon Blower wrote:Hi Nick and John (and list), I was about to write pretty much exactly what Nick just wrote - the serialization would be for short-term storage so I don't think there's a problem there (although I guess some people might try to misuse the serialization capability if it were provided). My _guess_ is that there is no need to keep open file handles and the overhead of opening a NetcdfDataset is mostly in the reading of the metadata into the relevant structures (Attributes, Axes etc), particularly if the dataset is an aggregation (actually it was aggregations that I had in mind when I suggested the persistent store in the first place). However, some testing would be needed of course - I don't really know. Maybe the metadata could be stored in some other way than serialization. We have done some analogous experiments with trying to use a relational database to store metadata but the problem is that the database gets complicated when you start dealing with projections and the like. Object-relational mapping could help to manage the complexity but this won't be trivial to code (e.g. could use Hibernate over an embedded database like H2).Maybe instead of going through the hassle of setting up an OR mapping,you might want to have a look at http://www.db4o.com/, which is an object database also for Java. It does not require class annotations or xml descriptions of mappings so it is rather quick to set up, although I must admit that I haven't tested it for performance against any other solution, yet. It also allows the database to be local, e.g. in a file and even allows for updates of an object's interface to some degree.
netcdf-java
archives: