SurrealDB: Unterschied zwischen den Versionen
Codica (Diskussion | Beiträge) |
Codica (Diskussion | Beiträge) |
||
| (5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 41: | Zeile 41: | ||
--data-binary $'{"ns":"myns", "db":"mydb", "sc": "another_scope"}\n' \ | --data-binary $'{"ns":"myns", "db":"mydb", "sc": "another_scope"}\n' \ | ||
$surreal_url/signup | $surreal_url/signup | ||
| + | |||
| + | Siehe auch | ||
| + | * https://ddlele.com/posts/surreal-db-row-security | ||
| + | * https://gist.github.com/koakh/fbbc37cde630bedcf57acfd4d6a6956b | ||
| + | * https://www.linode.com/docs/guides/managing-security-and-access-for-surrealdb/ | ||
== SELECT - Besonderheiten == | == SELECT - Besonderheiten == | ||
| Zeile 78: | Zeile 83: | ||
SELECT * FROM ONLY (select * from food)[0]; | 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. | ||
| + | |||
| + | === KI-Suche === | ||
| + | |||
| + | Da SurreaDB auch Vektoren beherrscht, kann man es auch mit Hilfe entsprechender KI-Datenmengen dazu bringen, semantische Suchen zu beherrschen. Siehe dazu: | ||
| + | |||
| + | * https://surrealdb.com/blog/moving-from-full-text-search-to-vector-search-in-surrealdb | ||
| + | |||
| + | == 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 | ||
--------- | --------- | ||
Aktuelle Version vom 16. August 2024, 05:27 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
Siehe auch
- https://ddlele.com/posts/surreal-db-row-security
- https://gist.github.com/koakh/fbbc37cde630bedcf57acfd4d6a6956b
- https://www.linode.com/docs/guides/managing-security-and-access-for-surrealdb/
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.
KI-Suche
Da SurreaDB auch Vektoren beherrscht, kann man es auch mit Hilfe entsprechender KI-Datenmengen dazu bringen, semantische Suchen zu beherrschen. Siehe dazu:
Nutzung mit TypeScript
Siehe