Bug: Record IDs with integer IDs are parsed as strings within JSON

[koakh]

Describe the bug

when I use node.js integration and create a record with id entity:01
and try to select it with same id entity:01it fails, but if I wrap the id with single or double quotes it works

but if I use a letter like entity:a01 it act as a string and works flawless

Steps to reproduce

run sample node js
https://surrealdb.com/docs/integration/libraries/nodejs

change db.create("person" to db.create("person:001"

now go to REPL and

> SELECT * FROM person;
[
  {
    "result": [
      {
        "id": "person:001"
      }
    ],
    "status": "OK",
    "time": "106.442µs"
  }
]

-- you note that record appears

-- now try with id
> SELECT * FROM person:001;
[
  {
    "result": [],
    "status": "OK",
    "time": "44.104µs"
  }
]

-- it fails, can't find record but if we wrap it in quotes it work

> SELECT * FROM "person:001";
[
  {
    "result": [
      {
        "id": "person:001"
      }
    ],
    "status": "OK",
    "time": "106.442µs"
  }
]

seems related to using quotes in ids,
we can get other similar issue using only the REPL

> CREATE person:002 CONTENT { name: "Tobie" };
[
  {
    "result": [
      {
        "id": "person:2",
        "name": "Tobie"
      }
    ],
    "status": "OK",
    "time": "184.179µs"
  }
]

-- we can note that 002 is converted to integer 2 ex person:2
-- and we can select it without quotes

> SELECT * FROM person:2;
[
  {
    "result": [
      {
        "id": "person:2",
        "name": "Tobie"
      }
    ],
    "status": "OK",
    "time": "180.692µs"
  }
]

-- warping id with quotes, result in id "person:003"

> CREATE "person:003" CONTENT { name: "Jamie" };
[
  {
    "result": [
      {
        "id": "person:003",
        "name": "Jamie"
      }
    ],
    "status": "OK",
    "time": "199.317µs"
  }
]

-- we can't select it with

> SELECT * FROM person:003;
[
  {
    "result": [],
    "status": "OK",
    "time": "47.791µs"
  }
]

but works with wrapped quotes

> SELECT * FROM "person:003";
[
  {
    "result": [
      {
        "id": "person:003",
        "name": "Jamie"
      }
    ],
    "status": "OK",
    "time": "64.041µs"
  }
]

seems the same issue from node.js, seems that surreal create ids wrapped in quotes from node js like if we use quotes in REPL

Expected behaviour

I expect to create a id with person:0001, and select it with person:0001
in both REPL and NodeJs integration
and if I create it in REPL with person:0001 I don't want to get the id converted to integer like person:1

If I want to use person:1
I explicit use it

SurrealDB version

surreal 1.0.0-beta.7 for linux on x86_6

Contact Details

marioammonteiro@gmail.com

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

[tetotechy]

sorry but I am still confused by a few things here. correct me if I am wrong but a query like select * from "person:003 (or even select * from "person:3") should parse the string as a literal string returning it verbatim, and NOT as a pointer/RecordID

special ids are allowed, according to the documentation, using backticks or angle brackets around the id name only, There is no mention of alternative syntax, which IMHO is correct. So why quoted strings like "person:1 or "person:001" should produce a valid pointer?!?

I don't think 6a3b1d9 addresses all the issues here. From what I got after tweaking with the patched version, the following is still possible:

create person:1 set name = "James"
create person:`001` set name = "Martha"

So far so good, we now have two Persons with different IDs, one numerical and the other one 'complex'. We can correcty select each of them as follows:

select * from Person:1           -> returns: James
select * from Person:`001`       -> returns: Martha

Consistently, select * from Person:"001" or select * from Person:"1" give an error. But when we do:

select * from "Person:001"

the DB returns James, which is arbitrary, as it would be arbitrary to return Martha as it was the case before -- also leading to duplications, now avoided through the patch -- simply because this syntax shouldn't be allowed, or am I wrong?
the same happens with other types of queries:

create "Person:001" set name = "Steven"

is correctly prevented, but again the error makes reference to the existence of Person:1 which is arbitrary. Even worse, allowing this syntax could mislead as in the following example:

update "Person:001" set age = 30

would give no error, setting the age field for James when it is likely that the intention was to address the Martha record
And with parameters it gets even more confusing:

let $prog = `001`; select * from type::thing('Person', $prog)

gives []

let $prog = "001"; select * from type::thing('Person', $prog)

gives Martha and

let $prog = "Person:001"; select * from type::thing('Person', $prog)

gives James

And through the interface of the Client Libraries the risk of messing up between what is a string in the client language and SurrealDB parsing syntax is VERY HIGH
I am thrilled at SurrealDB but the risk of messing up with IDs is not a secondary one before taking it into any serious consideration