[Gelöst] Generelles Problem mit SAS WebGUI-Mehrfachnutzung

[koyaanisqatsi]

War ja nur als Beispiel gedacht.
Dass du das irgendwie den User abnehmen willst ist mir schon klar.

Glücklicherweise braucht man bei PHP nicht wie früher einen Datenbankserver, sondern es funktioniert on the fly.

Aber nur, wenn du die Grundlagen dafür richtig umsetzt.

1. CREATE TABLE IF NOT EXSTS sehr hilfreich für die automatische Erstellung der Datenbankstruktur
2. Dann die Prüfung auf den Datensatz und gegebenenfalls dessen korrekte Erstellung.

Dann kann kaum was schiefgehen.
Denn das automatische Erstellen der Datenbank bei nichtvorhandensein (Simpler: Beim ersten Zugriff),
empfinde ich als grösste Stärke des "serverlosen" SQLite3 Systems.
...denn der Server ist die Datenbank selber.

 

[JL3]

ID ist übrigens nicht "hardcodiert". Mein Test mit CREATE TABLE cache (name VARCHAR(99) PRIMARY KEY,daten VARCHAR(999999999)) beweist das Gegenteil. Mein Key ist nun alphanumerisch und es funktioniert damit tadellos.

 

[koyaanisqatsi]

Ach JL3, ....

Wenn die id so definiert wird: id INTEGER PRIMARY KEY
...ist sie ein Autoincrement vom Typ Integer und lässt sich nicht ändern.
Und nur dann, will man denn die id 1 unbedingt haben, muss sie im Skript hardkodiert werden.

Natürlich lassen sich ids auch so definieren wie du es getan hast.
...dann ist sie aber (per Definition) keine Unveränderbare mehr.

 

[JL3]

Ach JL3, ....

Wenn die id so definiert wird: id INTEGER PRIMARY KEY
...ist sie ein Autoincrement vom Typ Integer und lässt sich nicht ändern.
Und nur dann, will man denn die id 1 unbedingt haben, muss sie im Skript hardkodiert werden.

Du redest von der ROWID.

Natürlich lassen sich ids auch so definieren wie du es getan hast.
...dann ist sie aber (per Definition) keine Unveränderbare mehr.

Nur so brauche ich sie.
Für was soll ich die ROWID "mitschleppen"?

Nachtrag: Ich meine, ich benötige sie nicht offen. Intern wird sie eh vergeben.

 

[JL3]

So, das Grundgerüst steht. Eine Funktion Daten eines Gerätes schreiben und eine, um sie zu lesen. Um die Datenbank an sich muss ich mich auch nicht mehr scheren, da ich alles in die beiden Funktionen integriert habe. Also ob die Datenbank existiert, ob das Gerät schon existiert usw. Letzteres wenn nein, wird der Datensatz aufgenommen, wenn ja, upgedatet. Läuft gut.

Aber es gibt noch ein Problem!
Wenn man ein nicht mehr gebrauchtes Pseudo rausnimmt aus sas........ in der Datenbank bleibt es als Zombi vorhanden. Eine Idee sowas zu verhindern?

 

[koyaanisqatsi]

Nun, das ist eine Ferndiagnose...

Wenn du das mit dem SaS internen Funktionen nicht in den Griff kriegst...
Sagen wir mal: Name wird auf Pseudodisplay...php oder Pseudoinfo....php gesetzt
...braucht es noch eine Prüfung auf Vorhandensein des Pseudoskriptes,
und wenn es nicht mehr existiert...
Entweder den Datensatz deaktivieren oder löschen.
Wobei für eine Deaktivierung mehr Schritte notwendig wären als ein simples löschen des Datensatzes.

Diese Prüfung gehört natürlich auch in die entsprechenden Funktionen.
So sollte auch ein Umbenennen des Skriptes im laufenden Betrieb keine Störungen verursachen.
...ich mach sowas nämlich ziemlich oft. :mrgreen:

 

[JL3]

Ich kann es nicht an den Pseudoscripten festmachen. Du vergisst schon wieder die Fritzboxgeräte. Theoretisch müsste sasap einmal die GESAMTE Datenbank durchgehen und mit dem gerade ermittelten tatsächlichen Bestand abgleichen. Was da zu viel ist, wird gelöscht. Kostet auch wieder eine Menge Abfragezeit... :gruebel:

Nachtrag: Ach was solls, lasst die Zombies leben :mrgreen:

 

[koyaanisqatsi]

Spätestens wenn die Datenbank neuangelegt wird sind die Untoten weg.
Aber eine geregelte Müllentsorgung ist nicht verkehrt.
Erinnerung: Viele viele viele viele Datensätze machen SQLite3 langsam

 

[JL3]

Ich tendiere gerade dazu, sozusagen einmal am Tag eine Funktion dafür laufen zu lassen. sasap müsste das dann nicht bei jedem Aufruf, sondern nur immer um 0h00. Mir fällt schon was diesbezüglich ein.

 

[koyaanisqatsi]

Eine "Totmannfunktion" wäre: Datenbank im laufenden Betrieb löschen
...sasap muss damit klarkommen und die wieder aufbauen können.

 

[JL3]

Das wird sasap sowieso können.
Für einzelne Zombie-Geräte gäbe es die Möglichkeit, bei jedem Durchlauf jedem aktiven Datensatz einen Timestamp zu verpassen. Dann ein SELECT darauf älter als eine Stunde, dann löschen des Datensatzes.

 

[koyaanisqatsi]

Dann ein SELECT darauf älter als eine Stunde, dann löschen des Datensatzes.

Das wäre dann: Pünktlicher als die berliner Müllabfuhr :mrgreen:

 

[JL3]

Inzwischen wird die Gerätedatenbank in der Alpha bereits von sasap on the fly befüllt. Ansonsten wird bei jedem Schaltvorgang aktualisiert, egal ob von sas oder sasap. Das Ganze arbeitet recht zügig. Noch etwas "Feinarbeit" und es wird eine Beta draus. Aber heute nicht mehr, denn es gibt nicht nur sas. :mrgreen:

@koyaanisqatsi: Danke für die vielen DB-Tipps und Hilfen. Ich denke, es hat sich für sas gelohnt.

Der "normale" Benutzer wird von der Umstellung auf eine DB nichts mitbekommen. Auch seine PseudoScripte laufen wie immer und ohne Umstellung. Nur alle Schaltvorgänge sind jetzt just in time und ohne Kollisionsgefahr.

 

[koyaanisqatsi]

Supi, ich freu mich, nicht ganz uneigennützig.
...hab ja schon im Hauptthread SQLite3 gepusht.



Ein Wunsch ist (mal wieder) in Erfüllung gegangen.
Dankeschön dafür.
Weihnachten im Märzen. :mrgreen:

 

[JL3]

Beta fertig und im Test. Absoluter Wahnsinn :mrgreen: Die Datenbank regeneriert sich sogar, wenn man sie mittendrin löscht innerhalb weniger Sekunden durch sas und sasap. Schaltkorrekturen werden on the fly durchgeführt. Ich habe es jetzt so hinbekommen, dass die Datenbank quasi unkaputtbar ist. Stimmt was nicht, wird sie regeneriert.

Jaja, ich konnte es nicht lassen und habe nochmal dran gebastelt. :mrgreen:

Muss nur noch die Zombies eliminieren, aber das ist auch kein Problem mehr

Wie ging nochmal einen Datensatz löschen?
Habe es hinbekommen, sodass diese ebenfalls on the fly gelöscht werden.