Applicatie settings. File-based of database?

[PdeBie]

Voor onze nieuw te bouwen Web API hebben we diverse settings die we door de hele API gaan gebruiken.
Een voorbeeld hiervan is het log-level. Dit is een setting waarmee we aangeven wat de applicatie allemaal logt.

Dit zou ik normaal gesproken in de applicationsettings opnemen in de Web.config. Gevolg is echter, dat als ik deze aanpas, de applicatie herstart. Wat ik dus wil voorkomen.

Ik zou deze setting dus op kunnen nemen in de database in een tabel settings. Gevolg: veel calls naar de database om de settings elke op te halen. Deels op te vangen door de settings per sessie te cachen.

Ik zou de setting ook op kunnen nemen in een losse file settings.xml (of iets dergelijks). Gevolg: meer HD traffic. Ook deels op te vangen door de settings per sessie te cachen.

Wat doen jullie met dit soort settings? Of maken jullie een mix hiervan?
Even benieuwd

Belangrijk is dus dat de settings op stel en sprong te wijzigen zijn in geval van 'nood'.

[MueR]

Ik zou daar gewoon een losse settings.xml (of .json) van maken. Die HD performance gaat het probleem niet zijn, dat lost de disk cache van je filesystem wel op als het echt zo vaak wordt aangeroepen.

[sig69]

Ik neem even voor het gemak aan dat het hierover gaat Versie beheer Web API? Oftwel .Net?
Ik zou inderdaad ook een losse settings file gebruiken. Als het .Net is kun je gewoon applicationsettings gebruiken met al het gemak van dien, maar een losse xml, json, txt, /care file volstaat ook prima.

Dit zou ik normaal gesproken in de applicationsettings opnemen in de Web.config. Gevolg is echter, dat als ik deze aanpas, de applicatie herstart. Wat ik dus wil voorkomen.

Applicationsettings hoeven niet perse in de web.config natuurlijk.

Ik zou de setting ook op kunnen nemen in een losse file settings.xml (of iets dergelijks). Gevolg: meer HD traffic. Ook deels op te vangen door de settings per sessie te cachen.

Volgens mij doet de ApplicationSettingsBase class zelf ook al aan caching, dus daar zou ik me niet al te druk over maken. Als je je zorgen moet maken over HD access naar een settings file zou ik me sowieso toch even achter m'n oren gaan krabbelen overigens...

[PdeBie]

Gaat inderdaad om dat project.

Je kan de application settings inderdaad ook buiten de web.config opnemen, maar als je die file wijzigt moet je alsnog de application domain herstarten, wil je de nieuwe settings in kunnen laden. Daarom dat ik naar een alternatief zocht.

En ja...ik vermeld het wel dat er meer HD traffic is, maar dat is meer een eerste ingave dan dat ik me er echt zorgen om maak. Ik verwacht geen duizenden/miljoenen calls per dag ofzo.

[sig69]

MSDN: ApplicationSettingsBase.Reload Method (System.Configuration)
MSDN: ApplicationSettingsBase.PropertyChanged Event (System.Configuration)

[Webgnome]

Ik zou het gewoon in een flat file gaan opslaan. Immers waar sla je database login's in op? Juist in een flat file omdat je er anders niet bij kan. Doe hetzelfde met dit soort settings. En geen gepruts met XML of JSON of iets in die strekking maar gewoon lekker flat ini format. Het is maar een settings file..

[sig69]

Tsja maar als je toch .Net gebruikt, gebruik dan ook gewoon de tools die er voor gemaakt zijn

[ValHallASW]

Webgnome schreef op woensdag 28 mei 2014 @ 21:11:
Ik zou het gewoon in een flat file gaan opslaan. Immers waar sla je database login's in op? Juist in een flat file omdat je er anders niet bij kan. Doe hetzelfde met dit soort settings. En geen gepruts met XML of JSON of iets in die strekking maar gewoon lekker flat ini format. Het is maar een settings file..

Ahja, een flat file. En hoe ziet die er dan uit?

code:

a=b

? En wat dan als gebruikersnaam of wachtwoord een =-teken bevatten?

XML en JSON hebben beiden als groot voordeel dat ze well-defined semantics hebben, en zijn dus een veel beter idee dan een .ini file.

Je kunt ook SQLite overwegen ('“SQLite is not a replacement for PostgreSQL. SQLite is a replacement for fopen()') -- zie http://use-the-index-luke...t-a-postgresql-conference

[Alex)]

pdebie schreef op woensdag 28 mei 2014 @ 17:00:
Gaat inderdaad om dat project.

Je kan de application settings inderdaad ook buiten de web.config opnemen, maar als je die file wijzigt moet je alsnog de application domain herstarten, wil je de nieuwe settings in kunnen laden. Daarom dat ik naar een alternatief zocht.

Een FileSystemWatcher in combinatie met het reloaden van je configfile zou goed moeten werken.

Loggingtools zoals NLog hebben hier ook al support voor aan boord.

[D-Raven]

Webgnome schreef op woensdag 28 mei 2014 @ 21:11:
Ik zou het gewoon in een flat file gaan opslaan. Immers waar sla je database login's in op? Juist in een flat file omdat je er anders niet bij kan. Doe hetzelfde met dit soort settings. En geen gepruts met XML of JSON of iets in die strekking maar gewoon lekker flat ini format. Het is maar een settings file..

Ik hoor dit soort opmerkingen wel vaker. Wat is het verschil tussen een zelfverzonnen ini format, en een bestaand wel bekend tekst formaat?

Een parser. Een parser welke je zelf moet bouwen, zelf moet onderhouden, en zelf bugs in moet fixen. Flat ini format zoals jij ze bedoeld is een oplossing uit het jaar 0.

Het is een veel betere keuze om een tekst formaat te pakken, waarvoor je simpelweg tegen een parser kunt zeggen, hier is mijn settings object, serialize maar naar tekst en vice versa.
Zelf een parser schrijven voor setting files is wel het laatste wat je wilt doen, helemaal omdat er al zoveel oplossingen zijn voor dit probleem.

[sig69]

In dit geval zijn applicationsettings denk ik dus gewoon het handigst. Desnoods met een filesystemwatcher er op nog inderdaad. Wel even goed tweaken want je krijgt iets van vier of vijf events voor elke change op je bent bestand

[ Voor 28% gewijzigd door sig69 op 31-05-2014 00:28 ]

[Creepy]

ValHallASW schreef op donderdag 29 mei 2014 @ 13:43:
[...]

Ahja, een flat file. En hoe ziet die er dan uit?

code:

a=b

? En wat dan als gebruikersnaam of wachtwoord een =-teken bevatten?

Geen probleem aangezien alleen de eerste = het scheidingsteken is. Alles wat er voor staat is de key en alles wat erachter staat is de value.

En de werking van INI files (of een properties files in de Java wereld) zijn tot in den treure beschreven en er zijn standaard parser voor direct beschikbaar. Dus om dat nu als voordeel van XML of JSON te noemen lijkt me niet zo handig Als je geneste zaken wilt opslaan wordt het een stuk lastigeren en moet je zelf gaan knutselen, iets wat met een JSON of XML formaat niet hoeft. Maar als dat niet nodig is, dan is een ini of een properties file minstens net zo goed bruikbaar

[ Voor 37% gewijzigd door Creepy op 31-05-2014 13:52 ]

[ValHallASW]

Creepy schreef op zaterdag 31 mei 2014 @ 13:48:
Geen probleem aangezien alleen de eerste = het scheidingsteken is. Alles wat er voor staat is de key en alles wat erachter staat is de value.

Klopt, maar snapt een naïef geschreven parser dat ook? Het gaat ongetwijfeld goed als je de standaard Windows-library of Java-library er voor gebruikt, maar dat is nou juist niet wat mensen doen: die denken 'oh, .ini, da's simpel, gewoon line.split('=')', of ze denken 'oh, .ini, dat kan met een regexp! (.*)=(.*)'.

En de werking van INI files (of een properties files in de Java wereld) zijn tot in den treure beschreven en er zijn standaard parser voor direct beschikbaar.

'tot in den treure beschreven' is overdreven: .ini files zijn niet goed gestandaardiseerd. Soms mag je ook een ':' gebruiken in plaats van een '=', soms mag je een '#' voor comments gebruiken in plaats van een ';', en wat het effect van aanhalingstekens is is ook implementatie-afhankelijk. Zie bv. Wikipedia: INI file . Uiteindelijk maakt dat natuurlijk niet zoveel uit omdat je voor één programma altijd dezelfde parser zult gebruiken, maar het maakt het geheel toch minder portable.

[ZpAz]

Weet niet in welke taal je het doet. Maar in PHP vind ik een config array altijd wel fijn. Zo doet Laravel het bijvoorbeeld ook.

e.g

PHP:

// Index.php of whatever
$config = require_once('config.php');

// Config.php
return array(
    'database' => array(
        'username' => 'something',
        .....
    )
);

[sig69]

Het is .Net. Gebruik gewoon de tools die er voor zijn, waarom zou je zelf gaan lopen klooien?

[PdeBie]

Zo, terug van een lang weekend weg. Zie dat er al leuk gediscussieerd is hier. Sorry dat ik er zelf weinig aan mee heb kunnen doen.

Alex) schreef op vrijdag 30 mei 2014 @ 18:31:
[...]
Loggingtools zoals NLog hebben hier ook al support voor aan boord.

Dat is een goede tip. Zal die er eens bij pakken. In het verleden al wel eens iets mee gedaan (niets heel extreem), maar dat is nog wellicht een goede
Bedankt!

--edit--
Enige waar ik mee zit is: http://nlog-project.org/2...ill-soon-be-released.html

Dat is een bericht van december 2013. Ik hoop niet dat de ontwikkeling er een beetje uit is, want wie weet wat er dan nog stiekem niet helemaal goed werkt.
--einde edit--

En @sig69: ik ben inderdaad niet van plan om zelf parsers etc. te gaan schrijven. Dat levert meer werk op en meer ellende dan een goede, bestaande oplossing te gebruiken. * PdeBie spreekt (helaas) uit ervaring

[ Voor 17% gewijzigd door PdeBie op 02-06-2014 09:35 ]

[sig69]

Ik ken NLog verder niet, maar log4net werkt prima, gebruik ik al jaren zonder enig probleem.

[PdeBie]

Zal log4net eens bekijken.

[Woy]

Zowel NLog als log4net zijn prima geschikt als logging frameworks. De reden dat er niet erg veel meer aan ontwikkeld wordt is waarschijnlijk omdat het alle benodigde features wel heeft, en anders eventueel zelf met een eigen logging appender toe te voegen.

NLog is wel een heel stuk eenvoudiger dan log4net. Zelf zou ik dan sneller voor log4net kiezen, maar als je niks speciaals wil is NLog nog net een tikkeltje eenvoudiger.

[Lethalis]

Waarom mag de applicatie niet herstarten?

Een web api hoort volledig stateless te zijn, dus dan boeit een herstart (van amper een seconde) toch ook niet?

PS: Wij slaan instellingen wel eens op in xml bestanden in de App_Data map en hebben zelf code die dat bestand uitleest.

[ Voor 36% gewijzigd door Lethalis op 02-06-2014 16:30 ]

[PdeBie]

Lethalis schreef op maandag 02 juni 2014 @ 16:28:
Waarom mag de applicatie niet herstarten?

Als we een update doen, dan is het niet anders inderdaad. Maar als ik snel even het 'log level' wil aanpassen wat er gelogd moet worden dan wil ik niet dat de applicatie herstart.

[Grijze Vos]

_Waarom_ niet? Je realiseert je dat die apppool om tig redenen sowieso uit zichzelf wel herstart?
Kijk, dat je niet wil dat ie elke 10 minuten herstart, sure. Maar zo vaak zit je toch ook niet te kloten met settings, of wel?

[Alex)]

Het loglevel aanpassen terwijl de boel in productie draait kan nuttig zijn als er anders belangrijke informatie verloren dreigt te gaan (bijvoorbeeld over de state van je applicatie) of als dit downtime met zich meebrengt voor productie-users (denk hierbij ook aan het heropbouwen van caches). Als je on the fly het loglevel kunt aanpassen zijn de gevolgen veel beperkter voor eindgebruikers.

[Janoz]

ValHallASW schreef op zaterdag 31 mei 2014 @ 14:31:
[...]

Klopt, maar snapt een naïef geschreven parser dat ook? Het gaat ongetwijfeld goed als je de standaard Windows-library of Java-library er voor gebruikt, maar dat is nou juist niet wat mensen doen: die denken 'oh, .ini, da's simpel, gewoon line.split('=')', of ze denken 'oh, .ini, dat kan met een regexp! (.*)=(.*)'.

Die mensen moet je uberhaupt ter plekke ontslaan. Dat soort volk wil je toch niet in je project hebben. Misschien is dat bij php-ers wel anders, maar als op mijn projecten (voornamelijk jee) iemand zit die niet Properties.load(Inputstream) gebruikt om een properties bestand in te laden mag hij zijn bureau op gaan ruimen.

[Kwistnix]

Ik zou denken dat de deployment omgeving toch ook wel sterk van invloed is. Als je multi-node gaat draaien uit schaalbaarheid / failover overweging, dan is een database tabel waar configuratie centraal is opgeslagen denk is snel de betere keuze. Simpel CRUD schermpje er bovenop en je kan direct overal - beveliging daargelaten - vandaan web-based je instellingen wijzigen. Zo'n opzet kan je in principe zo complex maken als je nodig hebt met node specifieke overrides e.d.
Maar goed als daar geen sprake van is, dan is KISS altijd een goede leiddraad en dan zou ik eerder voor file based gaan.

[Grijze Vos]

Alex) schreef op dinsdag 03 juni 2014 @ 00:01:
Het loglevel aanpassen terwijl de boel in productie draait kan nuttig zijn als er anders belangrijke informatie verloren dreigt te gaan (bijvoorbeeld over de state van je applicatie)

Welke state? Het gaat om een web applicatie. Ik mag toch hopen dat die (grotendeels) stateless is. Bovendien neem ik aan dat elke request netjes wordt opgeruimd als ie gedaan is. Dus die logging aanzetten voor de al gedane requests lijkt me sowieso een zinloos.

of als dit downtime met zich meebrengt voor productie-users (denk hierbij ook aan het heropbouwen van caches).

IIS restarts zijn rolling, m.a.w. de huidige requests termineren niet. Je kan idd afhankelijk van de traagheid van je applicatie een lagspike voor de end user tevoorschijn toveren. Maar dat kun je ook ondervangen met een goede loadbalancer evt. Caches is een goed punt. Hangt een beetje van je implementatie af of dat een probleem is of niet. Als je caches out of proces draaien doorgaans niet.

Als je on the fly het loglevel kunt aanpassen zijn de gevolgen veel beperkter voor eindgebruikers.

Mwoah, dat valt nog te bezien. Valt of staat met de degelijkheid van je architectuur.

[PdeBie]

Grijze Vos schreef op maandag 02 juni 2014 @ 21:35:
_Waarom_ niet? Je realiseert je dat die apppool om tig redenen sowieso uit zichzelf wel herstart?

Ja dat wel, maar als ik on-the-fly het log level aanpas wil ik dat liever niet.

Grijze Vos schreef op maandag 02 juni 2014 @ 21:35:
Maar zo vaak zit je toch ook niet te kloten met settings, of wel?

Nee, het liefst helemaal niet zelfs. Het komt echter wel eens voor dat een externe partij meldt dat er iets niet naar behoren werkt. Dan wil ik wel het loglevel direct aan kunnen passen, zonder dat anderen daar hinder van ondervinden.