Doofe Situation mit gemeinsam genutzten Dateiressourcen

[QuickAndDirty]

Zitat:

Zitat von jobo (Beitrag 1139650)

Stehen in den Konfigdaten auch individuelle Benutzereinstellungen? Dann müsste man sicher etwas filigraner vorgehen.

Ja !
Es gibt eben eine baum artige Konfigurationsdatein mit userspezifischen Zweigen...
Ich persönlich würde mir speziell diese Datei durch schreibend wünschen...sprich das jede änderung
sofort wirksam wird...habe schon mal angedacht eine "Teile Tabelle" dafür zu nehmen...
Aber ein erster schritt wäre sicher alles in blobs zu packen.

[QuickAndDirty]

Zitat:

Zitat von Sir Rufo (Beitrag 1139648)

Beim Zugriff auf die Daten prüft man nur schnell, ob der Zeitstempel des Objekts noch aktuell ist und aktualisiert das Objekt im Bedarfsfall.

Aktuell gemessen an der Datei oder aktuell in bezug auf einen Cache?

[Sir Rufo]

Zitat:

Zitat von QuickAndDirty (Beitrag 1139696)

Zitat:

Zitat von Sir Rufo (Beitrag 1139648)

Beim Zugriff auf die Daten prüft man nur schnell, ob der Zeitstempel des Objekts noch aktuell ist und aktualisiert das Objekt im Bedarfsfall.

Aktuell gemessen an der Datei oder aktuell in bezug auf einen Cache?

Ich sprach ja jetzt davon, alle Daten in einer DB zu halten.

Wenn du mORMot einsetzt, dann gibt es bei jedem Objekt (TSQLRecord) eine Eigenschaft "InternalState".
Der Server hat auch einen InternalState, der bei jeder DB-Änderung hochgesetzt wird.

Somit muss man nur diese beiden Werte vergleichen und wenn sich die unterscheiden, dann einmal einen Refresh, ansonsten ist alles schick.

Macht allerdings nur dann Sinn, wenn man eine eigene Konfigurations-DB einsetzt - in der Produktions-DB wird es ja wohl laufend Änderungen geben.