SurrealDB: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) |
Codica (Diskussion | Beiträge) |
||
| Zeile 85: | Zeile 85: | ||
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. | 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. | ||
| + | |||
| + | |||
| + | == Nutzung mit TypeScript == | ||
| + | |||
| + | Siehe | ||
| + | * https://dev.to/sebastian_wessel/how-to-design-a-surrealdb-schema-and-create-a-basic-client-for-typescript-o6o | ||
| + | ** https://github.com/sebastianwessel/surrealdb-client-generator | ||
--------- | --------- | ||
Version vom 23. April 2024, 11:08 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
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 1ausdrü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.
Nutzung mit TypeScript
Siehe