Bug: values inside backticks not recognized (was: Record id with backticks using "SET id =" instead of : returns random id instead of user-specified one)

[Dhghomon]

Describe the bug

When a record id is specified via the syntax SET id = (some value inside backticks) instead of recordname:somevalueinsidebackticks, a random id is returned instead.

Steps to reproduce

CREATE working as expected using : and backticks:

CREATE person:`george`;

[
    {
        "id": "person:george"
    }
]

CREATE not working as expected when other syntax is used:

CREATE person SET id = `george`;

[
    {
        "id": "person:slkdeot6qedorkljk6su"
    }
]

Similarly, using backticks for numbers and non-ascii characters works as expected in the former case but not in the latter:

CREATE person:`999`;

[
    {
        "id": "person:⟨999⟩"
    }
]

CREATE person SET id = `999`;

[
    {
        "id": "person:0uo30tquynqfr5s5h2b9"
    }
]

CREATE person:`하하하`;

[
    {
        "id": "person:⟨하하하⟩"
    }
]

CREATE person SET id = `하하하`;

[
    {
        "id": "person:ntdfgi0sqenhlclxqoxd"
    }
]

Expected behaviour

Either the output below, or an error.

CREATE person SET id = `george`;

[
    {
        "id": "person:george"
    }
]

CREATE person SET id = `999`;

[
    {
        "id": "person:⟨999⟩"
    }
]

CREATE person SET id = ``하하하;

[
    {
        "id": "person:⟨하하하⟩"
    }
]

SurrealDB version

1.2.1 for windows on x86_64

Contact Details

Slack

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[SquireOfSoftware]

Logs when creating something:

CREATE account SET name = "ACME Inc";

Returns:

[
    {
        "id": "account:smurp8yvr0q4cdmso619",
        "name": "ACME Inc"
    }
]

Logs:

2024-02-28T06:59:37.059520Z TRACE rpc/call:process:executor: surrealdb_core::dbs::iterator: Iterating: CREATE account SET name = 'ACME Inc' otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="11"
2024-02-28T06:59:37.059750Z TRACE rpc/call:process:executor: surrealdb_core::kvs::tx: Get Thing { __: 47, _a: 42, ns: "test", _b: 42, db: "test", _c: 42, tb: "account", _d: 42, id: String("smurp8yvr0q4cdmso619") } otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="11"

And running a back tick query:

CREATE account SET name = `John`;

Returns:

[
    {
        "id": "account:72zukn88960p3v9q1v3s"
    }
]

2024-02-28T06:54:05.081439Z TRACE rpc/call:process:executor: surrealdb_core::dbs::iterator: Iterating: CREATE account SET name = John otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="10"
2024-02-28T06:54:05.081592Z TRACE rpc/call:process:executor: surrealdb_core::kvs::tx: Get Thing { __: 47, _a: 42, ns: "test", _b: 42, db: "test", _c: 42, tb: "account", _d: 42, id: String("72zukn88960p3v9q1v3s") } otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="10"

Hmmm seems like it loses the field? In fact you can see the log line CREATE account SET name = John rather than have CREATE account SET name = 'John' which is what I would have expected? But unsure at what back ticks actually mean.

It also sounds like to me that perhaps the back ticks are making the parsing logic somehow lose the part of the SET statement?

This is proven with this query here:

CREATE account SET name = `Hello`, test = "Magic";

And the result is:

[
    {
        "id": "account:bd6dgnsxcmhn4k9konk3",
        "test": "Magic"
    }
]

The log lines are:

2024-02-28T07:10:34.434186Z TRACE rpc/call:process:executor: surrealdb_core::dbs::iterator: Iterating: CREATE account SET name = Hello, test = 'Magic' otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="16"
2024-02-28T07:10:34.434475Z TRACE rpc/call:process:executor: surrealdb_core::kvs::tx: Get Thing { __: 47, _a: 42, ns: "test", _b: 42, db: "test", _c: 42, tb: "account", _d: 42, id: String("bd6dgnsxcmhn4k9konk3") } otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="16"

Which you can see CREATE account SET name = Hello, test = 'Magic' meaning that the field name is just completely lost? And only the test field comes through?

[Dhghomon]

Which you can see CREATE account SET name = Hello, test = 'Magic' meaning that the field name is just completely lost? And only the test field comes through?

Good eye! I've changed the title accordingly, looks like this goes beyond just ids.

[SquireOfSoftware]

Interestingly I did some further testing, it looks like this also works?

SELECT * from `account`

Which gets interpreted as: SELECT * FROM account

Log line is here:

2024-02-28T07:16:14.761888Z TRACE rpc/call:process:executor: surrealdb_core::dbs::iterator: Iterating: SELECT * FROM account otel.kind="server" ws.id=89777ebf-1ec3-4514-89b1-660881443c83 rpc.service="surrealdb" rpc.method="query" otel.name="surrealdb.rpc/query" rpc.request_id="19"

Seems like there is some strange behaviour surrounding back ticks?

EDIT: Or maybe back ticks are just stripped out before being handed over to the core?

[Dhghomon]

Some more interesting backtick behaviour:

--Query
RETURN `'Hello'`;
--Output
null

--Query
SELECT * FROM { `num`: 0 };

--Output (Surrealist or SQL shell)
Parse error, won't work

--Output (curl)
[{"result":[{"um":0}],"status":"OK","time":"117µs"}]

[DelSkayn]

This is intended but indeed somewhat confusing behaviour.

Backticks are not an alternative way to create strings like with "foo" but are used to escape identifiers which don't conform to the regular rules of identifiers, i.e. contain non-ascii or non-alphanumeric characters or start with a digit. Similar to ⟨⟩

This is useful when your table contains a field with a name which would be confusing to parse in surrealql. 12345 for instance is a valid field for a table but parsing it as an identifier instead of a number would be confusing and therefore it needs to be escaped. If you wanted to create a table with the field 12345 you have to do

CREATE some_table SET `12345` = "some value";

In your example

CREATE person SET id = `george`;

Is equivalent to

CREATE person SET id = george;

george is an identifiers and since there is no george field here. The value of george is none and therefore the id field isn't being set. The behaviour here is the same as doing CREATE person SET id = NONE. I think what you wanted to do is actually done with CREATE person SET id = "george";

Your first example

CREATE id:`george`

is equivalent to

CREATE id:george

Which is why the id will be set to george in this case cause that is how creating with record-ids works.