Zeile 1: |
Zeile 1: |
| | | |
− | [https://github.com/surrealdb/surrealdb SurrealDB] ist v.a. eine Datenbank, kann aber auch als komplettes Backend für Webanwendungen fungieren. | + | [https://github.com/surrealdb/surrealdb SurrealDB] ist v.a. eine Datenbank, kann aber auch als komplettes Backend für Webanwendungen fungieren. Sein Alleinstellungsmerkmal ist der [https://surrealdb.com/docs/surrealdb/security/authentication#record-users Record User]. Damit können Regeln für die Aufnahme von neuen Usern und deren Anmeldungsverfahren in der Datenbank definiert werden. Für die |
| + | tatsächliche Aufnahme neuer Nutzer braucht man dann keinen "CREATE USER"-Befehl als vorhandener Nutzer auszuführen, sondern der neue Nutzer kann sich selbst anmelden. Dadurch kann man sich einen Applikationsserver sparen, der üblicherweise zwischen Datenbank und Frontend zu schalten ist. |
| | | |
| == Tools == | | == Tools == |
Zeile 14: |
Zeile 15: |
| == Skalierung == | | == Skalierung == |
| * für ein Cluster greift es wohl auf [https://www.pingcap.com/tidb/ TiDB] zurück | | * für ein Cluster greift es wohl auf [https://www.pingcap.com/tidb/ TiDB] zurück |
| + | |
| + | == Benutzung der HTTP/REST-API == |
| + | |
| + | Die HTTP-API von SurrealDB ist dokumentiert. |
| + | |
| + | === JSON ohne beginnendes Leerzeichen === |
| + | |
| + | |
| + | In Version 1.2.1 dürfen die per POST übermittelten Daten NICHT mit einem Leerzeichen beginnen. |
| + | |
| + | === Record Links mit r etc. === |
| + | |
| + | Record IDs, die als JSON-String übermittelt werden, [https://surrealdb.com/docs/surrealql/datamodel/ids müssen mit einem "r" beginnen]. |
| + | |
| + | Das führt zu einem nicht standardmäßigen JSON: |
| + | |
| + | { "owner": '''r'''"user:tobie" |
| + | } |
| + | |
| + | Das gilt auch für die längere Variante mit <code><record></code>: |
| + | |
| + | { "owner": '''<record<user>>'''"user:tobie" |
| + | } |
| + | |
| + | Ergänzt man den Cast nicht, kommt etwa folgende Fehlermeldung: ''"{result: Found 'user:tobie' for field `owner`, with record `xy`, but expected a record<user>, status: ERR, time: 0.01 µs}"'' |
| + | |
| + | Die entsprechenden Buchstaben sind |
| + | * für [https://surrealdb.com/docs/surrealql/datamodel/ids RecordIDs] "r" |
| + | * für UUID "u" |
| + | * für [https://surrealdb.com/docs/surrealql/datamodel/datetimes DateTime] "d" |
| + | * für String "s" |
| + | |
| + | === Scope-User (V1.x) === |
| + | |
| + | '''Hinweis: Der Scope User wird in Version 2.0 durch den Record User abgelöst. Der Scope heißt jetzt Access Method. Siehe https://surrealdb.com/docs/surrealdb/security/authentication#record-users ''' |
| + | |
| + | 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.<ref>Vgl. https://surrealdb.com/docs/surrealdb/surrealql/statements/select#the-only-clause .</ref> Dann kommt der Fehler |
| + | Expected a single result output when using the ONLY keyword |
| + | |
| + | Eine solche Menge ist aber akzeptabel, wenn sie |
| + | * durch <code>LIMIT 1</code> ausdrücklich auf eins begrenzt wird oder |
| + | * indem man mit <code>[0]</code> 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<ref>Vgl. https://surrealdb.com/docs/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 |
| | | |
| --------- | | --------- |