SurrealDB: Unterschied zwischen den Versionen

Version vom 20. März 2024, 13:16 Uhr

SurrealDB ist v.a. eine Datenbank, kann aber auch als komplettes Backend für Webanwendungen fungieren.

Tools

Die PgAdmin-Entsprechung für SurrealDB nennt sich surrealist.app

Libraries

https://www.npmjs.com/package/@adileo/surrealdb-ts-client

Betrieb hinter Proxy-Server

Wie betreibt man SurrealDB hinter einem NGinx-Proxy?
Die offizielle Dokumentation enthält auch eine Anleitung zum Betreiben von SurrealDB in einem Container auf fly.io.

Skalierung

für ein Cluster greift es wohl auf TiDB zurück

Benutzung der HTTP/REST-API

Die HTTP-API von SurrealDB ist dokumentiert.

Scope-User

Ein Scope wird mit DEFINE SCOPE angelegt.

Beim POST-Request des SIGNUP-Endpunkts wird ein JSON-Objekt mit folgenden Feldern übergeben:

NS - der Namespace
DB - die Datenbank
SC - der Scope-Name (wie hinter DEFINE SCOPE geschrieben)

Die Namen der Felder können auch klein geschrieben werden oder ausgeschrieben:

namespace
database
scope

In Version 1.2.1 dürfen die per POST übermittelten Daten NICHT mit einem Leerzeichen beginnen.

Beispiel eines SIGNUP:

 curl \
   -H "Accept: application/json" \
   --data-binary $'{"ns":"myns", "db":"mydb", "sc": "another_scope"}\n' \
 $surreal_url/signup

SELECT - Besonderheiten

ONLY Schlüsselwort

Das ONLY-Schlüsselwort funktioniert nur bei Angabe einer spezifischen Record-ID, nicht aber automatisch bei einer Menge, die nur ein Element enthält.^[1] Dann kommt der Fehler

 Expected a single result output when using the ONLY keyword

Eine solche Menge ist aber akzeptabel, wenn sie

durch LIMIT 1 ausdrücklich auf eins begrenzt wird oder
indem man mit [0] das erste Element der Menge auswählt (dann braucht man aber das SELECT ... FROM ONLY auch nicht mehr).

Beispiel:

Folgendes funktioniert:

 create  food:orange;
 select * from only food:orange;

Das bringt oben genannten Fehler:

 select * from  only food where id=="food:orange";

Dagegen hilft LIMIT 1:

 select * from only food where id=="food:orange" limit 1;

Oder einfach:

 (select * from food)[0];

Alternativen:

 RETURN (select * from food)[0];

oder

 SELECT * FROM ONLY (select * from food)[0];

Keine VIEWs

Auch wenn die Dokumentation behauptet, vorberechnete Tabellen (DEFINE TABLE ... AS SELECT ...) seien Views in rein relationalen Datenbanken vergleichbar^[2] handelt es sich dabei eher um Materialized Views. Die Ergebnisdaten werden also nicht erst bei der Abfrage einer precomputed table berechnet, sondern schon wenn die zugrunde liegenden Elemente geschaffen, aktualisiert oder gelöscht werden.

Eigentlich könnte das einem von der Funktionalität egal sein, aber die precomputed tables scheinen etwas komplizierter zu programmieren zu sein, so dass sie aktuell (Stand: März 2024) noch nicht produktiv genutzt werden können.^[3]

Wünschenswert wären daher herkömmliche - gerne auch nur lesbare, nicht beschreibbare - Views, die im Prinzip nur eine abgekürzte Schreibweise für umfangreichere SELECT-Statements darstellen. In der Zwischenzeit kann man sich produktiv nur mit komplexeren SELECT-Statements behelfen.

[1] Vgl. https://surrealdb.com/docs/surrealdb/surrealql/statements/select#the-only-clause .

[2] Vgl. https://surrealdb.com/docs/surrealdb/surrealql/statements/define/table#pre-computed-table-views .

[3] Vgl. https://github.com/surrealdb/surrealdb/issues/3546

[1]

[2]

[3]

@@ Zeile 78: / Zeile 78: @@
    SELECT * FROM ONLY (select * from food)[0];
+=== Keine VIEWs ===
+Auch wenn die Dokumentation behauptet, vorberechnete Tabellen (DEFINE TABLE ... AS SELECT ...) seien Views in rein relationalen Datenbanken vergleichbar<ref>Vgl. https://surrealdb.com/docs/surrealdb/surrealql/statements/define/table#pre-computed-table-views .</ref> handelt es sich dabei eher um Materialized Views. Die Ergebnisdaten werden also nicht erst bei der Abfrage einer precomputed table berechnet, sondern schon wenn die zugrunde liegenden Elemente geschaffen, aktualisiert oder gelöscht werden.
+Eigentlich könnte das einem von der Funktionalität egal sein, aber die precomputed tables scheinen etwas komplizierter zu programmieren zu sein, so dass sie aktuell (Stand: März 2024) noch nicht produktiv genutzt werden können.<ref>Vgl. https://github.com/surrealdb/surrealdb/issues/3546</ref>
+Wünschenswert wären daher herkömmliche - gerne auch nur lesbare, nicht beschreibbare - Views, die im Prinzip nur eine abgekürzte Schreibweise für umfangreichere SELECT-Statements darstellen. In der Zwischenzeit kann man sich produktiv nur mit komplexeren SELECT-Statements behelfen.
 ---------