Hi Jukka, > > I noticed that you have worked with INSERT triggers in > http://trac.osgeo.org/gdal/changeset/27936.
Don't mention it to Sandro: he will yell at me for possibly corrupting spatialite DBs ;-) I hope that what I've done is safe however, even if there's still some slight risk, in case what the triggers do evolve over time. Perhaps I should inspect a bit more the definitions of the trigger to be sure they are really safe to drop them temporarily. > > What would you say about the discussion in > https://groups.google.com/forum/#!searchin/spatialite-users/ > trigger/spatialite-users/A6gR--y2dr4/pkXg4nSdP2IJ > > I suppose that the new generation triggers will be created automatically if > GDAL is built with the next-to-come Spatialite 4.2.1 but it may take some > time before majority of GDAL users will have it. However, new triggers > should be backward compatible for all Spatialite 4.x versions. I wonder if > it would make sense to make GDAL to do something similar than SELECT > UpgradeGeometryTriggers that is mentioned in the thread. Perhaps, but that means incorporating the definition of the triggers inside OGR, which is risky since their definition might be spatialite version dependant. > Ten times more > speed when doing UPDATE of non-geometry attributes for each row is quite a > lot. Of coarse if Spatialite v. >=4.2.1 will be soon a standard for > building GDAL with Spatialite the unnecessary slow update trigger issue > will be solved automatically. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
