spatial key fix for null geometries

[svenschrader]

this is the fix I suggested in the thread
https://groups.google.com/forum/#!topic/h2-database/S2H67G6BHPg

[grandinj]

@nicolas-f care to look at this?

[svenschrader]

Please observe how the edited TestSpatial fails without the changes in SpatialDataType. A larger table is required to reveal this error. See above mentioned thread

[nicolas-f]

Hi,
Thanks for the PR
The spatial index should not be used by H2 when the query does not contain a spatial predicate. This way you do not have to insert null envelope in the RTree.

May be we have to update again the evaluation of spatial index cost here:
https://github.com/svenschrader/h2database/blob/master/h2/src/main/org/h2/index/SpatialTreeIndex.java#L187

[svenschrader]

Hi @nicolas-f
merci for your remark. You are right, setting some bogus envelope for the RTree is only a workaround.

However, the cost calculation you've mentioned does not seem to be an issue here(see below), BUT both the addRow and removeRow functions in MVSpatialIndex.java always iterate through all available indices (no matter what costs), and one of them is the Spatial one.

Please have a look at the updated MVTable, where null spatial keys for add and remove are ignored. It works on your TestSpatial unittest as well as on out local stresstests.

As for the query costs, they seem to be calculated when a SELECT by Geometry is performed. And null geometries won't be queried by this anyway.

What do you think?

[nicolas-f]

Nice ! well done. Thank you 👍