Skip to content

3.1 Config file

Jump to bottom
RnoldR edited this page Sep 12, 2024 · 4 revisions

Bevat configuratie-opties voor een DiDo projekt. Te vinden in \<projekt folder>/config/config.yaml.

Leveranciers

Uitgangspunt van DiDo is dat er een of meer leveranciers zijn waarvan elke leverancier een of meer projekten kent. Elk projekt leidt tot precies een tabel met data in de database. Die ene data tabel heeft daarnaast nog een aparte tabel met een beschrijving van alle kolommen zoals datatype, kolomnaam, kolombeschrijving, AVG-nivo, etc.

In config.yaml worden leveranciers gespecificeerd onder het kopje SUPPLIERS met daaronder (2 spaties inspringen) de namen van iedere leverancier. Per leverancier worden de projekten (minstens een) gedefinieerd.

SUPPLIERS:
  leverancier1:
    project1:
       schema_file: Bronanalyse_Leverancier1_project1
    project2:
       schema_file: Bronanalyse_Leverancier1_project2
  leverancier12:
    project1:
      schema_file: Bronanalyse_Leverancier2_project1
  leverancier3:
    project1:
      schema_file: Bronanalyse_Leverancier3_project1

In het bovenstaande voorbeeld is er een leverancier leverancier1 met als als schemafile Bronanalyse_Leverancier1. Dat betekent een aantal zaken:

  • de root directory bevat een subdirectory leverancier1
  • deze bevat vier files
    • de schemafile Bronanalyse_Leverancier1_project1.schema.csv
    • de metafile Bronanalyse_Leverancier1_project1.meta.csv
    • de schemafile Bronanalyse_Leverancier1_project2.schema.csv
    • de metafile Bronanalyse_Leverancier1_project2.meta.csv

Conventies

  • leveranciers- en projektnamen mogen uitsluitend uit letters en cijfers bestaan. Ieder ander teken kan later in de verwerking een probleem opleveren omdat bijvoorbeeld underscores (_) worden gebruikt om delen van de naam uit bijvoorbeeld een tabelnaam te filteren.
  • Aanbevolen wordt om voor ieder DiDo-projekt een Gitlab projekt aan te maken. Verder wordt aangeraden om per DiDo projekt een leverancier te specificeren en per leverancier een projekt. Er kunnen redenen zijn om hiervan af te wijken. De reden om meerdere projekten bij een leverancier toe te staan is gelegen in de referentiedata van P-Direkt. Dat zijn ongeveer 40 tabellen die elke keer opnieuw worden meegeleverd. Omdat het om veel tabellen gaat met soms heel weinig data is de mogelijkheid geboden om al deze kleine files als een geheel in DiDo te verwerken en als een DiDo-projekt in Gitlab op te slaan.

Datatype conversie

DiDo staat een beperkt aantal postgrestypes toe. Welke types dat zijn wordt gedefinieerd in de [dido.yaml file](DiDo bootstrap file) in de config directory van het dido projekt zelf (dus niet jouw voorbeeldprojekt dat we nu aan het nespreken zijn). De DiDo-beheerder kan de types naar jouw wens aanpassen.

Het kan zijn dat je datadefinities hebt uit bijvoorbeeld MSSQL of MariaDB die geconverteerd moeten worden naar postgres. Dit kan in beperkte mate worden gespecificeerd met de key DATATYPES gevolgd door een lijst met onder elkaar staande types als <leverancier datatype>:<postgres datatype>. Een 1-op-1 conversie is niet zo moeilijk, complexere conversies zul je met de hand moeten doen.

Datatype conversie vindt alleen plaats als in de schemafile de kolom datatype leeg is en leverancier_kolomtype een waarde bevat. In dat geval wordt de waarde van leverancier_kolomtype vertaald naar datatype. Mocht je een afwijkend datatype willen voor een bepaalde rij in de schemafile dan hoef je deze alleen maaar te specificeren in datatype. Een vertaling vindt alleen plaats als de kolom datatype in de [schemafile(Schemafile) leeg is.

Voorbeeld van de conversie van SAP-HANA data definities van P-Direkt naar Postgres definities.

# Allows conversion from leverancier_kolomtype to datatype when datatype is empty
DATATYPES:
    CHAR: text
    CUKY: text
    UNIT: text
    NUMC: numeric 
    DATS: date     
    QUAN: numeric
    DEC:  numeric  
    CURR: numeric

Projekt specs

De ROOT_DIR en WORK_DIR zijn subdirectories zijn relatief t.a.v. de PROJECT_DIR zoals gespecificeerd de -p/--project optie bij het opstarten van het programma. ROOT_DIR bevat specificaties die door de diverse DiDo applikaties worden ingelezen en vervolgens worden verwerkt en bewaard in de WORK_DIR.

ROOT_DIR: root
WORK_DIR: work

Database servers

Zie database servers.

Index toevoegen

DiDo kan een of meer indexen toevoegen door middel van de index instruktie. Voorbeeld

index:
  naam_index:
    naam: asc
  gpid_index:
    gpid: desc

De instruktie index wordt gevolgd door de naam van de index gevolgd door een rij met kolommen met per kolom of deze opklimmend (asc) of afdalend (desc) moet worden geindexeerd. Per tabel kunnen meerdere index worden gedefinieerd.

Eigen SQL code toevoegen

Soms is het nodig om eigen SQL code toe te voegen bij het aanmaken van de tabellen, bijvoorbeeld om het eigenaarschap van de tabellen goed te regelen. Dat kan door het statement SQL_SCRIPT \<filenaam>.yaml toe te voegen aan de config file. Dit is een yaml file die in ROOT_DIR/sql/leverancier wordt geplaatst. deze file bevat twee statements: AFFECTED_TABLES en SQL.

AFFECTED_TABLES: [<lijst met tabellen die de SQL statements betreffen>] of ['*']

De tabelnamen zijn de tabellen die worden aangemaakt door create-tables.py. Dus namen van het type leverancier_project_type_DATA|DESCRIPTION. Voorbeeld:

AFFECTED_TABLES: [spendportaal_spend_schema_data, spendportaal_spend_schema_description]

De SQL-statementsDe worden alleen toegepast op de schema tabellen van leverancier spendportaal en project spend.

SQL

SQL:
  1: SQL statement 1
  2: SQL statement 2

De SQL statements worden toegepast op de AFFECTED_TABLES. Voor iedere tabel uit AFFECTED_TABLES worden alle SQL statements doorlopen. De SQL statements kennen twee variabelen: {schema} (het schema van de DATA_SERVER_CONFIG) en {table}: de naam van de tabel die op dat moment doorlopen wordt. Voorbeeld:

AFFECTED_TABLES: ['*']
SQL:
  1: GRANT SELECT ON TABLE {schema}.{table} FOR USER user;

Kent aan alle aangemaakte tabellen het SELECT recht toe aan gebruiker user.

Dokumentatie

DiDo genereert op basis van de schema- en metafiles dokumentatie in markdown formaat. In principe worden alle kolommen getoond in die dokumentatie. Als je behoefte hebt aan slechts een beperkt aantal kolommen in de dokumentatie, of kolommen in een andere volgorde, specificeer dan welke kolommen je wilt zien in welke volgorde in de columns optie. Als deze een sterretje is ('*') is worden alle kolommen getoond.

# columns to show in documentation
COLUMNS:  ['*']

# Show only column name and description
COLUMNS
- kolomnaam
- beschrijving
Clone this wiki locally