Dsmr-reader: Mogelijkheid om pg_schema te configureren

[rogierlommers]

Ik zou graag de mogelijkheid hebben om het gebruikte postgres schema in te stellen. Voor zover ik nu kan zien is dit niet mogelijk. De python postgres library ondersteunt dit volgens mij wel, echter ik ben hier niet zo in thuis :).

[dennissiemensma]

Bedankt voor je vraag. Ik weet niet exact wat je bedoelt met schema, doel je op de databasenaam?
Een aantal dingen kun je zelf wijzigen: https://dsmr-reader.readthedocs.io/en/latest/env_settings.html#db-name

Verder is het goed om te weten dat het project Django gebruikt en niet specifiek de postgres-client, dus in dat opzicht zijn de mogelijkheden wat beperkt.

[rogierlommers]

Hey @dennissiemensma , snelle reactie! Relaxt. Wat betreft het "schema". Ik zal iets meer context geven. Ik heb hier thuis een home-servertje waarin ik o.a. dus dsmr-reader draai, naast nog wat ander spul zoals Miniflux (rss aggregator). Nu zou ik ervoor kunnen kiezen om per applicatie een eigen postgres instantie te draaien, echter dit vind ik voor thuisdoeleinden nogal overkill.

De oplossing is het draaien van een "shared postgres database", met daarin per applicatie een schema. Alle tabellen, views, indexes, functies, etc. houd je dan netjes bij elkaar, per applicatie. Maar wel maar één postgres instantie. De gulden middenweg dus,

Ik heb even gekeken naar het Django framework en ik vond deze stackoverflow vraag. Ofwel, als je aanvullende opties mee kunt geven richting de DB interface, dan moet het lukken.

'options': '-c search_path=dsmr-reader'

[dennissiemensma]

Dank voor je aanvulling. Begrijp ik het goed dat je met "postgres instantie" de Postgresql-installatie op het systeem bedoelt?

Je kunt namelijk meerdere "databases" (ipv schema's) binnen dezelfde installatie gebruiken om hetzelfde te bereiken qua groeperen van tabellen en indexes etc. Met pg_dump of pg_dumpall kun je dan makkelijk backups maken van (een deel van) de complete installatie, zonder dat je er meerdere installaties voor nodig hebt.

Als je toch een enkele DB wil met een apart schema dan kun je dit proberen in te stellen in je config:

dsmrreader/settings.py

"""
    This used to be the local settings file until DSMR-reader 4.x.
    Please use .env instead. See: https://dsmr-reader.readthedocs.io/en/latest/faq/v4_upgrade.html
"""
from dsmrreader.config.production import *

DATABASES['default']['OPTIONS'] = {
    'options': '-c search_path=dsmr-reader'
}

[rogierlommers]

Hey @dennissiemensma en @xirixiz Ik heb bovenstaande optie geprobeerd en inderaad: werkt goed. Door het search_path mee te geven in de dsmrreader/settings.py-file, forceer je het gebruik van een bepaald schema. Een aantal opmerkingen:

1. Het schema moet wel bestaan op het moment dat dsmr wordt gestart
2. Hoe krijgen we deze "flag" nu beschikbaar via de docker container? Kunnen we iets verzinnen -een env var ofzo?- waardoor mensen het search_path mee kunnen geven? Iest dat lijkt op:

if search_path is set (als env)
  dan dsmrreader/settings.py aanpassen:
    stukje toevoegen m.b.t. search-path

Ik denk dat het enkel wijzigingen in de Dockerfile moeten zijn, vandaar dat ik @xirixiz (als maintainer van dsmr-reader-docker) include in deze thread. Dsmr-reader zelf support het gebruik van schema's al. Eens?

Misschien iets op deze line? Iets dat lijkt op:

if [[ -n "${PG_SCHEMA}" ]]; then # waarbij PG_SCHEMA dus een ENV var is
  # bash code to add the stuff
fi

[xirixiz]

In het verleden heb ik veel settings op een dergelijke manier toegepast, maar later heeft Dennis aangepast dat env vars gebruikt konden worden om bepaalde configuratie opties te zetten. Mogelijk kan Dennis dit ook meenemen.

Ik kan het natuurlijk oplossen met onhandige bash scripting, maar ik denk dat het mooier is dit op een nette manier te integreren.

[xirixiz]

Ik weet niet goed of dit mogelijk is bijvoorbeeld (https://github.com/dennissiemensma/dsmr-reader/edit/v4/dsmrreader/config/defaults.py):

DB_OPTION_SEARCH_PATH = config('DB_OPTION_SEARCH_PATH', default=public)

if DB_OPTION_SEARCH_PATH:
    DATABASES['default']['OPTIONS'] = 'options': '-c search_path=' + DB_OPTION_SEARCH_PATH + '

Op die manier kan je DB_OPTION_SEARCH_PATH als env var meegeven aan de Docker container. Vervolgens wordt in Python (DSMR Reader) de waarde geinterpreteerd en gezet op basis van de env var. Veel netter dan via bash, maar het hangt even van @dennissiemensma af hoe hij hier tegenaan kijkt.

[dennissiemensma]

@rogierlommers ik begrijp je verzoek en ik vind het op het randje zitten wat standaard configureerbaar hoort te zijn.

Meestal hanteer ik daarvoor handmatige workarounds voor specifieke gevallen, zoals bovenstaande voor jou, zodat niet-standaard installaties en wensen wat buiten de normale flow blijven. Is het werkbaar voor je om die toevoeging in dsmrreader/settings.py zelf aan te houden?

[rogierlommers]

@rogierlommers ik begrijp je verzoek en ik vind het op het randje zitten wat standaard configureerbaar hoort te zijn.

Meestal hanteer ik daarvoor handmatige workarounds voor specifieke gevallen, zoals bovenstaande voor jou, zodat niet-standaard installaties en wensen wat buiten de normale flow blijven. Is het werkbaar voor je om die toevoeging in dsmrreader/settings.py zelf aan te houden?

Sowieso even beginnen met complimenten. Lekkere communicatie hoor! Lekker actief project. 👍
Wat betreft het "wijzigen" van de settings.py file: ik maak nu gebruik van de "plain" docker image van @xirixiz . Het liefst bouw ik geen eigen versie / fork hiervan. Ook deel ik jouw mening dat het eigenlijk niet thuishoort in dsmr-reader zelf, maar dat het eigenlijk prima in het docker-project kan.

@xirixiz , sta jij open voor een merge-request waarin ik het volgende doe:

• in jouw run.sh
• checken op gevulde env var db_schema
• indien gevuld, dan de searc_path optie toevoegen aan de settings file

Dan zouden we er namelijk zijn.... en ben ik HEUUUUL blij 👍 .

[dennissiemensma]

Ik denk dat vanuit xirixiz wellicht hetzelfde geldt, want hiermee verplaatsen we alleen de vraag. We kunnen namelijk wel voor elke afwijking een toevoeging maken, maar dat moet ook tot in de einde der tijden in stand, onderhouden en gedocumenteerd worden. Dat vind ik namelijk een van de grotere uitdagingen binnen dit soort projecten, waardoor ik dergelijke uitzonderingen tegenwoordig minder snel doorvoer.

Waar ik mee zit is dat ik je enerzijds uiteraard niet ga vertellen hoe je je systemen en databases moet draaien, want daar ben je vanzelfsprekend helemaal vrij in. Wat echter wel een gevolg daarvan is is dat je daarmee, andersom, iets niet-standaards vraagt en eigenlijk vind ik, als ik even heel zwart-wit mag zijn, het in dit soort gevallen initieel meer iets voor de eindgebruiker om mee dealen.

Daarom ben ik meer voorstander van de handmatige workarounds in deze situaties. Mocht nou over een tijdje blijken dan veel mensen hetzelfde willen dan heroverweeg ik het. Een goed voorbeeld zijn andere verzoeken voor envvars, die ik initieel hebt afgehouden en anderen te vragen dezelfde wijziging handmatig te doen: #1080, #1085, #1105.

[rogierlommers]

Ik snap jullie overwegingen. @xirixiz , deze settings.py-file. Is deze bedoeld voor dergelijke aanpassingen? Dan kan ik hem namelijk mounten vanuit de host en ben ik er ook.

Eigenijk is de vraag: verwacht jij dat de inhoud van deze file aan wordt gepast in de toekomst?

[dennissiemensma]

Je bent helemaal vrij om zelf een andere settings.py te gebruiken. Het is niet standaard, maar de file staat (bewust) niet onder versiebeheer en hoeft alleen compatible te zijn met je versie van DSMR-reader.

In de huidige opzet is het belangrijk dat er bovenaan een import gedaan wordt van production.py. Dit is overigens al 4 jaar zo, dus ik verwacht daar geen wijzigingen in.
Het beste is om de releasenummering in de gaten te houden: Minor updates (v4.1 > v4.2) vereisen doorgaans geen wijzigingen van de gebruiker.
Major updates (v4.x > v5.x) gebruik ik om wijzigingen door te voeren waarbij de gebruiker vrijwel altjd wat moet doen (v3, v4).

Je kunt dit lokaal gebruiken:

settings.py

# """
#     This used to be the local settings file until DSMR-reader 4.x.
#     Please use .env instead. See: https://dsmr-reader.readthedocs.io/en/latest/faq/v4_upgrade.html
# """
from dsmrreader.config.production import *

try:
    DJANGO_DATABASE_OPTIONS_SEARCH_PATH = config('DJANGO_DATABASE_OPTIONS_SEARCH_PATH', cast=str)
except UndefinedValueError:
    pass
else:
    DATABASES['default']['OPTIONS'] = dict(
        options='-c search_path={}'.format(DJANGO_DATABASE_OPTIONS_SEARCH_PATH)
    )

Envvar

DJANGO_DATABASE_OPTIONS_SEARCH_PATH=dsmr-reader

[rogierlommers]

Hey, laatste vraag; dan laat ik je met rust :).
Ik moet nu gewoon zelf een settings.py-file vanuit de host de container in.
Inhoud is als volgt:

"""
    This used to be the local settings file until DSMR-reader 4.x.
    Please use .env instead. See: https://dsmr-reader.readthedocs.io/en/latest/faq/v4_upgrade.html
"""
from dsmrreader.config.production import *

DATABASES['default']['OPTIONS'] = {
    'options': '-c search_path=energy'
}

Dit werkt op zich prima. Begrijp ik het goed dat jouw suggestie als voordeel heeft dat het dan vanuit een env var komt? Is dat het enige voordeel?

[dennissiemensma]

Correct, dan kun je zelf kiezen welke variant je voorkeur heeft. Je mag zoveel vragen als je wilt hoor ;)