A scalable, distributed, collaborative, document-graph database, for the realtime web

Overview

SurrealDB Icon


SurrealDB Logo SurrealDB Logo

SurrealDB SurrealDB is the ultimate cloud
database for tomorrow's applications

Develop easier.   Build faster.   Scale quicker.


         

     

LinkedIn   Twitter   Youtube   Dev   Discord   StackOverflow


  What is SurrealDB?

SurrealDB is an end-to-end cloud native database for web, mobile, serverless, jamstack, backend, and traditional applications. SurrealDB reduces the development time of modern applications by simplifying your database and API stack, removing the need for most server-side components, allowing you to build secure, performant apps quicker and cheaper. SurrealDB acts as both a database and a modern, realtime, collaborative API backend layer. SurrealDB can run as a single server or in a highly-available, highly-scalable distributed mode - with support for SQL querying from client devices, GraphQL, ACID transactions, WebSocket connections, structured and unstructured data, graph querying, full-text indexing, geospatial querying, and row-by-row permissions-based access.

For more details see the features, documentation, or roadmap.

  SurrealDB Cloud

SurrealDB can run as a single-instance, or as a highly-available, highly-scalable cluster. If you don't want to manage your own database, we can run SurrealDB for you, in the Cloud, with just a couple of clicks. To get started with SurrealDB Cloud see our website.

  Getting started

Getting started with SurrealDB is as easy as starting up the SurrealDB database server, choosing your platform, and integrating its SDK into your code. You can easily get started with your platform of choice by reading one of our tutorials.

Client side apps
Server side code

  Documentation

For guidance on installation, development, deployment, and administration, see our documentation.

  Installation

SurrealDB is designed to be simple to install and simple to run - using just one command from your terminal. In addition to traditional installation, SurrealDB can be installed and run with HomeBrew, Docker, or using any other container orchestration tool such as Docker Compose, Docker Swarm, Rancher, or in Kubernetes.

  Install on macOS

The quickest way to get going with SurrealDB on macOS is to use Homebrew. This will install both the command-line tools, and the SurrealDB server as a single executable. If you don't use Homebrew, follow the instructions for Linux below to install SurrealDB.

brew install surrealdb/tap/surreal

  Install on Linux

The easiest and preferred way to get going with SurrealDB on Unix operating systems is to install and use the SurrealDB command-line tool. Run the following command in your terminal and follow the on-screen instructions.

curl -L https://install.surrealdb.com | sh

  Install on Windows

The easiest and preferred way to get going with SurrealDB on Windows is to install and use the SurrealDB command-line tool. Run the following command in your terminal and follow the on-screen instructions.

iwr https://ps1.surrealdb.com -useb | iex

  Run using Docker

Docker can be used to manage and run SurrealDB database instances without the need to install any command-line tools. The SurrealDB docker container contains the full command-line tools for importing and exporting data from a running server, or for running a server itself.

docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start

  Community

Join our growing community around the world, for help, ideas, and discussions regarding SurrealDB.

  Contributing

We would    for you to get involved with SurrealDB development! If you wish to help, you can learn more about how you can contribute to this project in the contribution guide.

  Security

For security issues, kindly email us at [email protected] instead of posting a public issue on GitHub.

  License

Source code for SurrealDB is variously licensed under a number of different licenses. A copy of each license can be found in each repository.

For more information, see the licensing information.

Comments
  • Bug: Unable to install windows-amd64 binary version of SurrealDB

    Bug: Unable to install windows-amd64 binary version of SurrealDB

    Describe the bug

    OS: Windows 10 x64

    
    PS C:\WINDOWS\system32> iwr https://windows.surrealdb.com -useb | iex
    
     .d8888b.                                             888 8888888b.  888888b.
    d88P  Y88b                                            888 888  'Y88b 888  '88b
    Y88b.                                                 888 888    888 888  .88P
     'Y888b.   888  888 888d888 888d888  .d88b.   8888b.  888 888    888 8888888K.
        'Y88b. 888  888 888P'   888P'   d8P  Y8b     '88b 888 888    888 888  'Y88b
          '888 888  888 888     888     88888888 .d888888 888 888    888 888    888
    Y88b  d88P Y88b 888 888     888     Y8b.     888  888 888 888  .d88P 888   d88P
     'Y8888P'   'Y88888 888     888      'Y8888  'Y888888 888 8888888P'  8888888P'
    
    Fetching the latest database version...
    Fetching the host system architecture...
    Installing surreal-v1.0.0-beta.5
     for windows-amd64...
    Invoke-WebRequest : The remote server returned an error: (403) Forbidden.
    At line:54 char:5
    +     Invoke-WebRequest $DownloadUrl -OutFile $Executable -UseBasicPars ...
    +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
       eption
        + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
    
    PS C:\WINDOWS\system32>
    

    Steps to reproduce

    Run the installation script

    iwr https://windows.surrealdb.com -useb | iex
    

    Expected behaviour

    It's supposed to install SurrealDB.

    SurrealDB version

    1.0.0-beta.5

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug 
    opened by jareer12 30
  • Fix build issues and simplify building from source

    Fix build issues and simplify building from source

    What is the motivation?

    Currently building from source can be frustrating, especially when one wants to enable either TiKV or FoundationDB. This is an attempt to make builds easier and provide a more consistent user experience across different systems. Building from source should be simple and painless regardless of the user's experience with Rust and C/C++.

    Ideally, one shouldn't even need to know what the build dependencies of this project are or what language it's written in in order to be able to compile it. Once they install the build tool, running it or building it from source should just work and be a single command away without even needing to clone the repo first.

    After cloning this repo, Rust developers too should be able to start making changes after running only a single command that prepares their environment for all the dependencies they need to build successfully. This is, of course, assuming they already have our build tool installed and configured. Both of which should, theoretically at least, be simple and straight-forward steps. It's possible to eliminate that single command entirely and have the environment be prepared automatically once one cds into this project.

    I know these are hefty promises :smile: On paper, the build tool I'm proposing comes with all these features and more. However whilst I have been using it since 2014 and I love and swear by it, I have never used it outside Linux distros so your mileage may vary if you use a different system.

    What does this change do?

    This changeset packages this repo using the Nix package manager. More specifically it turns this repo into a Nix flake.

    • [X] Add a basic Nix flake (POC)
    • [x] Add support for cross compiling to different targets
    • [x] Add support for building static binaries
    • [x] Add a test in the CI
    • [x] Add documentation

    Once this PR lands one can run the server without even needing to clone the repo first by running

    nix run github:surrealdb/surrealdb
    

    This will download the latest commit on main, compile and run it. Specific branches, tags or even commits can be specified easily too, for example nix run github:surrealdb/surrealdb/v1.0.0-beta.8. If we add this project to the Flake registry, that command can even be shortened to nix run surrealdb or nix run surreal.

    To just install it in one's PATH

    nix profile install github:surrealdb/surrealdb
    

    Developers will simply need to run nix develop to prepare their environment so that cargo build just works (rustup won't be needed as Nix takes over the functions of installing the Rust toolchain and targets).

    What is your testing strategy?

    Made sure that all tests still pass and added more CI jobs to test building with Nix.

    Is this related to any issues?

    It directly addresses https://github.com/surrealdb/surrealdb/issues/97. It will also help with https://github.com/surrealdb/surrealdb/issues/52 though it requires that nix develop be run first before cargo build.

    Have you read the Contributing Guidelines?

    opened by rushmorem 16
  • Bug: unknown variant `Polygons`

    Bug: unknown variant `Polygons`

    Describe the bug

    Selecting a record that contains a MultiPolygon crashes the database.

    Steps to reproduce

    Run the following documented query:

    UPDATE university:oxford SET locations = {
    	type: "MultiPolygon",
    	coordinates: [
    		[
    			[ [10.0, 11.2], [10.5, 11.9], [10.8, 12.0], [10.0, 11.2] ]
    		],
    		[
    			[ [9.0, 11.2], [10.5, 11.9], [10.3, 13.0], [9.0, 11.2] ]
    		]
    	]
    };
    

    Select the record or export the database:

    SELECT * FROM university:oxford;
    

    The database crashes with the following error message:

    thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Syntax("unknown variant `Polygons`, expected one of `Point`, `Line`, `Polygon`, `MultiPoint`, `MultiLine`, `MultiPolygon`, `Collection`")', lib/src/sql/value/value.rs:97:60
    

    Expected behaviour

    Selects should return the record successfully and exporting should work as expected. I have already identified the source of the bug and will prepare and submit a pull request shortly.

    SurrealDB version

    surreal 1.0.0-beta.7 for linux on x86_64

    Contact Details

    No response

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug 
    opened by rushmorem 15
  • Bugfix: #1309 Hashed implementation of `Uniq<Array>`

    Bugfix: #1309 Hashed implementation of `Uniq`

    Thank you for submitting this pull request! We appreciate you spending the time to work on these changes.

    What is the motivation?

    While I have yet to actually use this method for anything, according to the Contribution Guide "Query execution time" is very important and this will lower it exponentially in the use of this method.

    However, the time taken for hashing, might be slower for small Arrays with large items, but I think the time will be negligible. Or we could add a condition for < 10 Values to use the O(n^2) method.

    What does this change do?

    Added #[derive(Hash)] to almost every struct under lib/src/sql (anything that linked back to Value). And changed the Uniq<Array> implementation to use a HashSet rather than having a nested loop.

    Some things I'm not sure are the best I've had to do, such as the implementation for Hash on Number is as follows

    https://github.com/surrealdb/surrealdb/blob/84be58dda0d44b3670c30a649b4e056cef54ffb4/lib/src/sql/number.rs#L323-L331

    And according to what I've researched, this works, except has unintuitive behavior for NaNs

    Then, for Geometry, the only sensible way I could tell to do this is with

    https://github.com/surrealdb/surrealdb/blob/84be58dda0d44b3670c30a649b4e056cef54ffb4/lib/src/sql/geometry.rs#L511-L515

    And while this might make it a bit slower for Values containing Geometry Values, I think it should still work as the method is idempotent.

    What is your testing strategy?

    1. Ran cargo test and it passed
    2. Built and ran SurrealDB
    3. Created a record with 10k values each a random number between 0 and 2999
    4. Ran SELECT array::distinct(v) FROM test:test;
    5. Did steps 2, 3 and 4 on the main release build of SurrealDB
    6. Compared the output of steps 4 and 5 to verify they are the same and that 4 was faster

    Is this related to any issues?

    Fixes #1309

    Have you read the Contributing Guidelines?

    opened by AL1L 14
  • SurrealDB is not a database

    SurrealDB is not a database

    Is your feature request related to a problem?

    I just came across SurrealDB and was curious about the underlying system in place. However, very soon I realized that calling Surreal a database is extremely misleading, especially from an academic point of view (and since I research database systems this is very incorrect).

    What you're building is essentially a "query engine" or "data API" on top of other actual databases. It is like what Hasura and Timescale are to Postgres. And they clearly don't say that they are "ultimate databases" in their own right. It is like saying a REST API providing access to SQLite is a database.

    Describe the solution

    I like the idea of being able to choose a database engine, but please reconsider your framing of what Surreal actually is to avoid confusion. "End to end" and "ultimate" are very misleading.

    Alternative methods

    NA

    SurrealDB version

    1.0.0-beta.7

    Contact Details

    No response

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    opened by firedupmike 14
  • Support additional build metadata

    Support additional build metadata

    What is the motivation?

    The current version reported, for example 1.0.0-beta.7 does not carry enough information to pinpoint the exact commit built when building from source. SemVer allows for adding additional build metadata by adding it after the + sign. This can be very helpful for debugging.

    What does this change do?

    It makes it possible to specify optional build metadata using the SURREAL_BUILD_METADATA environment variable. Build tools like Nix can set this variable to something like 20220926.a72052a. The first part is the date on which the commit being built was made. The second part is the short form of the commit. In this case the version reported by surreal version will be 1.0.0-beta.7+20220926.a72052a.

    What is your testing strategy?

    Made sure tests still pass and tested the functionality in a separate PR.

    Is this related to any issues?

    Extracted from https://github.com/surrealdb/surrealdb/pull/100.

    Have you read the Contributing Guidelines?

    opened by rushmorem 9
  • Bug: Database panics on connection reset

    Bug: Database panics on connection reset

    Describe the bug

    I was in the process of writing some benchmarks with Benchmark.js & nodemon to restart my tests on save when I came across an error I believe should be handled in RUST.

    Basically, in between a running a benchmark for the update query, I updated the source causing nodemon to restart the process. In effect this sudden disconnection of the client caused SurrealDB to completely panic and die.

    thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" })', src/net/rpc.rs:64:37
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    Aborted (core dumped)
    

    I think we should handle the Result rather than unwrap to avoid killing the database process.

    Steps to reproduce

    1. Run Surrealdb NodeJs client query on a loop (as would happen in a bechmark)
    2. Then suddenly kill the client to abruptly disconnect from the server.
    3. The Tokio thread dies in a panic.

    Expected behaviour

    The match expression should be used to handle the Result instead of Result::unwrap() which currently causes the database process to panic and terminate.

    SurrealDB version

    1.0.0-beta.7

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug 
    opened by mugendi 9
  • Bug: Rust compile error

    Bug: Rust compile error

    Describe the bug

    When I try to compile surrealdb in rust I get the following error

    --- stderr thread 'main' panicked at 'called Result::unwrap() on an Err value: Error { kind: NotFound, message: "program not found" }', C:\Users\Vijay.cargo\registry\src\github.com-1ecc6299db9ec823\rquickjs-sys-0.1.7\build.rs:136:10 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

    I have tried the following in Cargo.toml

    [dependencies] surrealdb = "1.0.0-beta.7"

    I have tried using git.

    Steps to reproduce

    create a new cargo.toml with and compile [dependencies] surrealdb = "1.0.0-beta.7"

    Expected behaviour

    --- stderr thread 'main' panicked at 'called Result::unwrap() on an Err value: Error { kind: NotFound, message: "program not found" }', C:\Users\Vijay.cargo\registry\src\github.com-1ecc6299db9ec823\rquickjs-sys-0.1.7\build.rs:136:10 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

    SurrealDB version

    1.0.0-beta.7

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug 
    opened by vjkolaventy 9
  • Bug: Scope session management example doesn't work.

    Bug: Scope session management example doesn't work.

    Describe the bug

    Scope management listed at https://surrealdb.com/features#permissions doesn't seem to work.

    Steps to reproduce

    -- Enable scope authentication directly in SurrealDB
    DEFINE SCOPE account SESSION 24h
    	SIGNUP ( CREATE user SET email = $email, pass = crypto::argon2::generate($pass) )
    	SIGNIN ( SELECT * FROM user WHERE email = $email AND crypto::argon2::compare(pass, $pass) )
    ;
    
    curl --request POST --header "Content-Type: application/json" --header "NS: test" --header "DB: test" --header "SC: account" --data "{'email': 'test', 'pass': 'apple'}" http://10.0.0.24:8000/signup
    
    {"code":403,"details":"Authentication failed","description":"Your authentication details are invalid. Reauthenticate using valid authentication parameters.","information":"There was a problem with authentication"}
    

    Expected behaviour

    A return of a JWT.

    SurrealDB version

    surreal v1.0.0-beta.7 for windows on x86_64

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug awaiting confirmation 
    opened by bit-garden 8
  • Feature: Don't auto-convert dates to ISO 8601

    Feature: Don't auto-convert dates to ISO 8601

    Is your feature request related to a problem?

    Maybe this is related to #1301.

    TL;DR It seems to me that it would be better for the developer to determine the way his data is stored and not have SurrealDB decide that for him/her.

    I need to store an array of dates and wish there were a simple way to keep them in the string format I assign them. For example, taking advantage of the CONTENT statement is really convenient for me since I can update data directly from a javascript (stringified) object:

    UPDATE thing:id123 CONTENT { 
      dateArray: [
        '2022-10-06', 
        '2022-10-07', 
        '2022-10-08'
      ] 
    }
    

    To avoid surrealDB's conversion, I would need to run my object through a string conversion function (or make a more complex query statement) before sending the UPDATE/CONTENT statement, and this would be complicated with nested dates. It would end up looking something like this:

    UPDATE thing:id123 CONTENT { 
      dateArray: [
        time::format('2022-10-06', '%Y-%m-%d'), 
        time::format('2022-10-07', '%Y-%m-%d'), 
        time::format('2022-10-08', '%Y-%m-%d')
      ]
    }
    

    I guess I'm just trying to figure out a way to reduce complexity, and I'd have to do this a little differently in each case depending on the structure of the data. In addition, auto-formatting to UTC time complicates things for me because I want the date to be the same regardless of the time zone I'm in. Think of a calendar feature for a school (which is basically what I'm building): If I'm viewing the calendar from a different time zone all of the dates would be shifted unless I process the dates after receiving them which can get a little annoying.

    All of this would be much simpler if SurrealDB didn't auto-convert my dates. If a developer needs the date in UTC 8601 format, it is probably the case that they're already working with those formats in whatever codebase they're using.

    Describe the solution

    Don't auto-convert the dates! It seems to me that it would be better for the developer to determine the way their data is stored. For example, leave it up to them to cast a string to a datetime if they so desire:

    UPDATE test:123 SET date = <datetime> '2022-10-05'
    
    // output
    result: [
      id: 'test:123',
      date: '2022-10-05T00:00:00Z'
    ] 
    

    ...and this is a feature that's already built into SurrealDB! (https://surrealdb.com/docs/surrealql/datamodel/casting)

    Alternative methods

    Doing lots of somersaults in my code 😄 !

    SurrealDB version

    Nightly release 13 (Oct 4, 2022)

    Contact Details

    No response

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    feature 
    opened by ntorrey 7
  • Feature: array::flatten(array) -> array

    Feature: array::flatten(array) -> array

    Is your feature request related to a problem?

    From Kiiq#2386 on Discord:

    I have 3 entities: User, Image, Category (simplified)

    DEFINE TABLE user SCHEMAFULL;
    DEFINE FIELD images ON user VALUE $value OR [];
    DEFINE FIELD images.* ON user TYPE record (image);
    
    DEFINE TABLE image SCHEMAFULL;
    DEFINE FIELD name ON image TYPE string;
    
    DEFINE TABLE category SCHEMAFULL;
    DEFINE FIELD name ON category TYPE string;
    

    I then have a graph edge between image and category with:

    RELATE ${imageId}->belongsTo->${categoryId}
    

    I want to query a user and select distinct categories of all their images:

    SELECT *, images->belongsTo->category.name as categories FROM user;
    

    The query works, but the contents of categories is an array containing an array for each image's categories. Like so:

    categories: [
      ['category a', 'category b', 'category c'], // this is image 1
      ['category a', 'category d'] // this is image 2
      ['category b'] // image 3
    ]
    

    What I would like is it flattened and distinct:

    categories: ['category a', 'category b', 'category c', 'category d']
    

    Describe the solution

    A new array function that takes in an array of arrays and returns the flattened version of it.

    array::flatten(array) -> array

    SELECT * FROM array::flatten([[1,2], [3, 4], [5, 6]]);
    

    would return

    [1, 2, 3, 4, 5, 6]
    

    This is very similar to, and could even replace array::combine(array, array) -> array as the functionality of array::combine(arr1, arr2) is the same as array::flatten([arr1, arr2])

    Alternative methods

    • A [ FLATTEN ] [ DISTINCT ] extension to the select syntax, but this doesn't seem to follow the same idiom as the rest of the database
    • Allow array::combine(array, array) and array::union(array, array) to take an arbitrary amount of arguments and add a spread operator. E.g. array::combine(...[[1,2], [3,4]]) -> [1, 2, 3, 4]. Although this seems complex and I personally have no idea how to start in implementing that.

    SurrealDB version

    surreal 1.0.0-beta.8+20220930.c246533 for linux on x86_64

    Contact Details

    Allen#0001 on Discord (or here on GitHub)

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    feature 
    opened by AL1L 7
  • Bug: Edges imported from Export script return nothing when queried

    Bug: Edges imported from Export script return nothing when queried

    Describe the bug

    If you create edges using the RELATE command and then export your database using the official EXPORT CLI command, then the export script attempts to recreate the EDGES using UPDATE <edgename> set a=b, c=d, etc.int he same way it creates normal table records.

    When you import this script, you can query the EDGE table and see the data is there, but querying with the -> and <- operators no longer work.

    Steps to reproduce

    Use the RELATE command to create some edges between objects so normal. User CLI to export the database.

    Clear the DB and use CLI to import that script. Try to query using those edges (eg select ->likes->user from user:a).

    You will not get any results returned from the edges, even if you did before the import.

    Expected behaviour

    Imported edges should work exactly as they did before the export/import process, and return the data.

    Having dug into this, the edges are exported using UPDATE <edgename> set a=b, c=d format. If you try to create edges using CREATE or UDPATE then when you query that edge table directly the records look identical, but those not created with RELATE will not return records.

    Therefore RELATE must be doing something special under the hood which CREATE and UPDATE don't do, perhaps she indexing or something for -> and <- to follow?

    I guess either change EXPORT to output RELATE instead of UPDATE?

    SurrealDB version

    surreal 1.0.0-beta.8+20220930.c246533 for macos on x86_64

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug 
    opened by chrisrudman 0
  • Feature: Run a post http request with form data

    Feature: Run a post http request with form data

    Is your feature request related to a problem?

    Yes: I currently cannot interact with the cloudflare images api as it requires either no body + no content-type header, or a body with form data. multipart/form-data

    Describe the solution

    Allow http::post (and others) functions to perform the request with form-data instead of a json body (maybe actually also allow plain content etc)

    Alternative methods

    None, at least, I haven't found one

    SurrealDB version

    v1.0.0-beta.8 in Docker

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    feature triage 
    opened by kearfy 0
  • Feature: Define multiple queries within ()

    Feature: Define multiple queries within ()

    Is your feature request related to a problem?

    Yes: Currently it is not possible to define multiple queries in for example, a single event or a auth provider. Because of this we have to apply some very nasty hacks to get the data we need: https://github.com/theopensource-company/kards-social/commit/c6f240a7cb834bfe0e1b9c8d46ae8301a85f302b#diff-708af38fc6a67607fab39bb426a820ec4b289bbf831594d2f566ec141902c37bR45

    There is a bigger thread with more issues: https://discord.com/channels/902568124350599239/1018618253695795261/1038785938098229348

    Describe the solution

    The only issue I could come up with, allowing multiple queries, is what data to return, so lets introduce a return statement!

    (
      let $variable = (select * from bla);
      update test set value=$variable;
      return (select * from other);
    )
    

    Alternative methods

    Use very nasty workarounds as shown above

    SurrealDB version

    v1.0.0-beta.8 in Docker

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    feature triage 
    opened by kearfy 0
  • Bug: Parse error from JavaScript function containing }

    Bug: Parse error from JavaScript function containing }

    Describe the bug

    The parser throws "Parse error" in most cases where a JavaScript function contains a closing curly brace }, even if it is in a comment.

    Steps to reproduce

    These cause the error:

    CREATE person SET scores = function() {
      // }
      return [1,2,3].map(v => v * 10);
    };
    
    CREATE person SET scores = function() {
      // {}
      return [1,2,3].map(v => v * 10);
    };
    
    CREATE person SET scores = function() {
      var x = {}
      return [1,2,3].map(v => v * 10);
    };
    
    CREATE person SET scores = function() {
      function x () {};
      return [1,2,3].map(v => v * 10);
    };
    

    I've found that having an opening brace with any subsequent space does not cause the error:

    CREATE person SET scores = function() {
      // { }
      return [1,2,3].map(v => v * 10);
    };
    

    Expected behaviour

    Valid syntax including } should be parsed and not cause an error.

    SurrealDB version

    surreal 1.0.0-beta.8+20220930.c246533 for linux on x86_64

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    bug 
    opened by m59peacemaker 0
  • Feature: Ecto Driver for Elixir / Phoenix

    Feature: Ecto Driver for Elixir / Phoenix

    Is your feature request related to a problem?

    No

    Describe the solution

    I'd love to use SurrealDB in Elixir / Phoenix. Not sure, I shall make this request to Elixir / Phoenix team or you.

    Alternative methods

    Creating a driver for Ecto

    SurrealDB version

    v1.0.0-beta.8

    Contact Details

    No response

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    feature triage 
    opened by nesimtunc 1
  • Feature: [Security] Allow loading secrets from filles

    Feature: [Security] Allow loading secrets from filles

    Is your feature request related to a problem?

    Loading secrets from environment variables is not secure, other users and program can view the environment of a program at /proc/pid/environment. This is why docker created docker secrets (a program can read a secret from a path) Systemd has the same mechanicsm with LoadCredential. (addtional benefit, I'm currently the maintainer of surrealdb on the nixos distribution, we won't be able to make a proper service that people can easily use without a mechanism to load a secret from a file, since secrets in environment variable are considered a security issue).

    Describe the solution

    For secrets (like user and pass), allowing those to be read from a file would be more secure. So potentially having a cli argument like --user-path and --password-path (with corresponding environment variables) would be the best here.

    Alternative methods

    Passing secrets as environment variables

    SurrealDB version

    1.0.0-beta.8

    Contact Details

    [email protected]

    Is there an existing issue for this?

    • [X] I have searched the existing issues

    Code of Conduct

    • [X] I agree to follow this project's Code of Conduct
    feature triage 
    opened by happysalada 0
Releases(v1.0.0-beta.8)
Owner
SurrealDB
A scalable, distributed, collaborative, document-graph database, for the realtime web
SurrealDB
A programmable document database inspired by CouchDB written in Rust

PliantDB PliantDB aims to be a Rust-written, ACID-compliant, document-database inspired by CouchDB. While it is inspired by CouchDB, this project will

Khonsu Labs 699 Nov 29, 2022
RefineDB - A strongly-typed document database that runs on any transactional key-value store.

RefineDB - A strongly-typed document database that runs on any transactional key-value store.

Heyang Zhou 376 Nov 21, 2022
A programmable document database inspired by CouchDB written in Rust

BonsaiDb Formerly known as PliantDb. Not yet released on crates.io as BonsaiDb. BonsaiDb aims to be a Rust-written, ACID-compliant, document-database

Khonsu Labs 696 Nov 24, 2022
Scalable and encrypted embedded database with 3-tier caching

Infinitree is a versioned, embedded database that uses uniform, encrypted blobs to store data.

Symmetree Research Labs 112 Nov 13, 2022
Embedded graph database

CQLite An embedded graph database implemented in Rust. This is currently a pre-release. It has not been extensively tested with 'real-world work-loads

Tilman Roeder 77 Nov 15, 2022
Embedded graph database

CQLite An embedded graph database implemented in Rust. This is currently a pre-release. It has not been extensively tested with 'real-world work-loads

Tilman Roeder 78 Nov 28, 2022
Distributed transactional key-value database, originally created to complement TiDB

Website | Documentation | Community Chat TiKV is an open-source, distributed, and transactional key-value database. Unlike other traditional NoSQL sys

TiKV Project 12.3k Dec 1, 2022
small distributed database protocol

clepsydra Overview This is a work-in-progress implementation of a core protocol for a minimalist distributed database. It strives to be as small and s

Graydon Hoare 19 Dec 2, 2021
Distributed SQL database in Rust, written as a learning project

toyDB Distributed SQL database in Rust, written as a learning project. Most components are built from scratch, including: Raft-based distributed conse

Erik Grinaker 4.5k Dec 4, 2022
Distributed, version controlled, SQL database with cryptographically verifiable storage, queries and results. Think git for postgres.

SDB - SignatureDB Distributed, version controlled, SQL database with cryptographically verifiable storage, queries and results. Think git for postgres

Fremantle Industries 5 Apr 26, 2022
Embedded Distributed Encrypted Database (Research).

EDED Embedded Distributed Encrypted Database. Research projects to support ESSE. WIP Distributed design features Adapt to personal distributed usecase

Sun 2 Jan 6, 2022
A high-performance, distributed, schema-less, cloud native time-series database

CeresDB is a high-performance, distributed, schema-less, cloud native time-series database that can handle both time-series and analytics workloads.

null 1.7k Nov 27, 2022
The rust client for CeresDB. CeresDB is a high-performance, distributed, schema-less, cloud native time-series database that can handle both time-series and analytics workloads.

The rust client for CeresDB. CeresDB is a high-performance, distributed, schema-less, cloud native time-series database that can handle both time-series and analytics workloads.

null 12 Nov 18, 2022
Simple document-based NoSQL DBMS from scratch

cudb (a.k.a. cuda++) Simple document-based noSQL DBMS modelled after MongoDB. (Has nothing to do with CUDA, has a lot to do with the Cooper Union and

Jonathan Lam 3 Dec 18, 2021
XLite - query Excel (.xlsx, .xls) and Open Document spreadsheets (.ods) as SQLite virtual tables

XLite - query Excel (.xlsx, .xls) and Open Document spreadsheets (.ods) as SQLite virtual tables XLite is a SQLite extension written in Rust. The main

Sergey Khabibullin 1.1k Dec 1, 2022
A highly scalable MySQL Proxy framework written in Rust

mysql-proxy-rs An implementation of a MySQL proxy server built on top of tokio-core. Overview This crate provides a MySQL proxy server that you can ex

AgilData 174 Nov 29, 2022
RedisLess is a fast, lightweight, embedded and scalable in-memory Key/Value store library compatible with the Redis API.

RedisLess is a fast, lightweight, embedded and scalable in-memory Key/Value store library compatible with the Redis API.

Qovery 145 Nov 23, 2022
Scalable and fast data store optimised for time series data such as financial data, events, metrics for real time analysis

OnTimeDB Scalable and fast data store optimised for time series data such as financial data, events, metrics for real time analysis OnTimeDB is a time

Stuart 2 Apr 5, 2022
The most efficient, scalable, and fast production-ready serverless REST API backend which provides CRUD operations for a MongoDB collection

Optimal CRUD Mongo Goals of This Project This is meant to be the most efficient, scalable, and fast production-ready serverless REST API backend which

Evaluates2 1 Feb 22, 2022