There was some recent discussion about the performance of OpenJUMP with large datasets. I started tweaking my FeatureCache code to use HSQL this morning. This might provide a workable solution to the problem. I hope it might also be used in the future to support "non-spatial" features
Its a little trickier than I thought because I have to alter tables in HSQL if there are changes to the FeatureSchema in OpenJUMP. (For example: The user adds an attribute to a layer.) The only other alternative is to make the FeatureCache read only, and I don't want to do that. I'm also trying to figure out a good way to "cache" insert statements at the low-level of my FeatureCahce. (This is in the FeatureGate.) I don't want to execute an insert/update statement everytime a Feature needs to be stored in permanent memory, but I don't want to loose Features temporarily stored in the FeatureGate before insert/update statements are executed. I think I can do this by adding some code to the OpenJUMP shutdown hook to flush each FeatureCache. Another issue is that HSQL only supports one database in "embedded" mode by default. This means all tables underlying the FeatureCache's within all JUMP projects on a single computer would need to be stored in the same database. I'm not sure if this is the most elegant solution. I'm not a JDBC or HSQL wizard, so if you have suggestions for me they are appreciated. (I will be storing JTS Geometries as BLOB's. Thanks for that earlier suggestion.) I'll keep everyone posted on my slow progress. :] The Sunburned Surveyor ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
