BAGv2 SQL errors

[sebastic]

Het uitvoeren van een aantal SQL scripts door etl.sh faalt:

2021-11-19 18:34:02,138 fileinput INFO Read/parse for start for file=sql/fill-reltables.sql....
2021-11-19 18:34:02,296 fileinput INFO Read/parse ok for file=sql/fill-reltables.sql
2021-11-19 18:34:02,345 dboutput INFO executing SQL
2021-11-19 18:34:02,368 postgis INFO Connecting to dbname=bagv2 user=bag host=dbserver port=5432
2021-11-19 18:34:03,173 postgis DEBUG Connected to database bagv2
2021-11-19 18:34:03,507 postgis ERROR error column "aanduidingrecordinactief" does not exist
LINE 24:         aanduidingRecordInactief,
                 ^
HINT:  There is a column named "aanduidingrecordinactief" in table "verblijfsobjectpand", but it cannot be referenced from this part of the query.
 in query: -- Fills the (Legacy) relation tables and nevenadres.

2021-11-19 18:34:03,522 fileinput INFO Read/parse for start for file=sql/create-views.sql....
2021-11-19 18:34:03,523 fileinput INFO Read/parse ok for file=sql/create-views.sql
2021-11-19 18:34:03,524 dboutput INFO executing SQL
2021-11-19 18:34:03,524 postgis INFO Connecting to dbname=bagv2 user=bag host=dbserver port=5432
2021-11-19 18:34:03,613 postgis DEBUG Connected to database bagv2
2021-11-19 18:34:03,837 postgis ERROR error column "begindatumtijdvakgeldigheid" does not exist
LINE 18:       beginDatumTijdvakGeldigheid <= LOCALTIMESTAMP
               ^
 in query: -- Views voor BAG tabellen

2021-11-19 18:34:03,868 fileinput INFO Read/parse for start for file=sql/create-indexes.sql....
2021-11-19 18:34:03,922 fileinput INFO Read/parse ok for file=sql/create-indexes.sql
2021-11-19 18:34:03,923 dboutput INFO executing SQL
2021-11-19 18:34:03,923 postgis INFO Connecting to dbname=bagv2 user=bag host=dbserver port=5432
2021-11-19 18:34:03,976 postgis DEBUG Connected to database bagv2
2021-11-19 18:34:05,018 postgis ERROR error column "geovlak" does not exist
 in query: -- Author: Just van den Broecke

Ook adres.sh faalt:

2021-11-19 18:34:24,640 fileinput INFO Read/parse for start for file=sql/adres/adres-tabel.sql....
2021-11-19 18:34:24,641 fileinput INFO Read/parse ok for file=sql/adres/adres-tabel.sql
2021-11-19 18:34:24,641 fileinput INFO all files done
2021-11-19 18:34:24,641 dboutput INFO executing SQL
2021-11-19 18:34:24,641 postgis INFO Connecting to dbname=bagv2 user=bag host=dbserver port=5432
2021-11-19 18:34:24,727 postgis DEBUG Connected to database bagv2
2021-11-19 18:34:25,001 postgis ERROR error relation "verblijfsobjectactueelbestaand" does not exist
LINE 54:    FROM verblijfsobjectactueelbestaand v
                 ^
 in query: --

Dit is met GDAL 3.3.3 op Debian unstable, en de (volledige) lvbag-extract-nl.zip data uit de Atom feed.

[sebastic]

Het onderliggende probleem lijk te zijn dat sql/finalize-tables.sql faalt, in de meest recente run door gebrek aan disk space:

2021-11-22 17:28:17,843 chain INFO Running Chain: input_sql_post|output_postgres_sql
2021-11-22 17:28:17,843 fileinput INFO Read/parse for start for file=sql/finalize-tables.sql....
2021-11-22 17:28:17,891 fileinput INFO Read/parse ok for file=sql/finalize-tables.sql
2021-11-22 17:28:17,892 dboutput INFO executing SQL
2021-11-22 17:28:17,894 postgis INFO Connecting to dbname=bag-test user=bag host=dbserver port=5432
2021-11-22 17:28:18,044 postgis DEBUG Connected to database bag-test
2021-11-22 18:26:27,594 postgis ERROR error could not extend file "base/17240/485872.2": No space left on device

Stetl gaat vervolgens door met de andere acties in de chain die falen omdat de columns niet zijn renamed e.d.

M.i. zou stetl moeten stoppen wanneer een error voorkomt.

[sebastic]

Waarom is gekozen het schema aan te passen om op BAG v1 te lijken?

De bulk van de data is in BAG v2 niet meer beschikbaar (aanduidingrecordinactief/aanduidingrecordcorrectie/officieel/inonderzoek), is het niet beter om het database schema zoveel mogelijk een directe match te laten zijn van de XML data wat door NLExtract verwerkt wordt zoals het ook voor BAG v1 was?

Applicaties die voor het BAG v1 schema ontwikkeld zijn moeten geport worden voor het nieuwe schema, dat is niet vreemd voor een nieuwe major versie.

[reinvantveer]

M.i. zou stetl moeten stoppen wanneer een error voorkomt.

Ik schaar mij achter deze insteek: het wordt wat graven in de logs als stetl niet bij de eerste onherstelbare fout stopt, en het kost onnodig tijd waarbij het proces tevergeefs doorloopt. Ik denk dat dit vraagt om een wat andere benadering van de foutafhandeling in NLExtract of STETL.

[petersaalbrink]

M.i. zou stetl moeten stoppen wanneer een error voorkomt.

Ik kan me hier ook in vinden.