[gdal-dev] List all the (possible) errors of a single transaction

[jratike80]

Hi,

One workaround is to use -skipfailures and compare afterwards which IDs in
the source data are not present in the target table. Skipfailures is forcing
the transaction size into one row and it may be deadly slow if the output is
GeoPackage because initializing/committing a transaction in SQLite is slow.
With PostGIS as an outlut it is not as slow. A dry run into some some fast,
not transactual format like GeoJSON could be used as some sort of test but
that does not test the database constraints.

If you know your database and the contraints that you have you should be
able to make quite nice tests by running SQL against the source data. But
having a typeless SQLite as source can make it harder to write the SQL
tests. That may even be a reason for your problems (field reserved for
integers contains text etc.).

I wonder why even the database engines would go on after finding the first
error in the transaction. The whole transaction must be rollbacked in any
case so why not to quit sooner rather than later?



-Jukka Rahkonen-



ghtmtt wrote
> Hi all and happy new year!
> 
> as suggested some days ago [0] I've set up a vrt file that I use to 
> export many tables from a gpkg to a PG.
> 
> In the PG DB there are some constraints and with the vrt files all works 
> as expected: if an error (like a wrong value caught by the constraint) a 
> total rollback is made and nothing is written in the PG DB.
> 
> But what if I've more than one single error on the gpkg? It seems (to 
> me) that when ogr2ogr identifies the first error the process is stopped.
> 
> Is there a way to list ALL the (possible) errors of a single transaction 
> (like a dry run)?
> 
> Cheers and thanks for any hint
> 
> Matteo
> 
> 
> [0] https://lists.osgeo.org/pipermail/gdal-dev/2020-December/053209.html
> _______________________________________________
> gdal-dev mailing list

> gdal-dev at .osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html