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 18: |
Zeile 19: |
| | | |
| Die HTTP-API von SurrealDB ist dokumentiert. | | 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) === | | === Scope-User (V1.x) === |
Zeile 87: |
Zeile 115: |
| === Keine VIEWs === | | === 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. | + | 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> | | 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> |