Comments (5)
Which you can see
CREATE account SET name = Hello, test = 'Magic'
meaning that the fieldname
is just completely lost? And only thetest
field comes through?
Good eye! I've changed the title accordingly, looks like this goes beyond just ids.
from surrealdb.
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?
from surrealdb.
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?
from surrealdb.
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"}]
from surrealdb.
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.
from surrealdb.
Related Issues (20)
- Bug: `update merge` should not check required fields HOT 1
- Bug: License unfinished HOT 1
- Bug: cant have id field in struct HOT 1
- Bug: INFO / USE... query parsing error (RUST SDK) HOT 2
- Bug: Table Permissions Doesn't Seem To Be Working With Embedded Select Statement HOT 3
- Bug: Flutter app with embedded Rust failing to compile as a result of SurrealDB dependency usage HOT 1
- Bug: Deadlock encountered HOT 3
- Bug: Index not used when comparing with "==" HOT 1
- Bug: Db(Unreachable("This feature won't go live with sql1, so delete this branching")) HOT 2
- Bug: Vector NN search count does not respect WHERE clause HOT 1
- Feature: Query builder like syntax
- Bug: Paginating data (START / OFFSET) gets exponential slower with bigger datasets (from 380ms to 468970ms) HOT 1
- Bug: Cannot insert/create a data that contains a large vector size HOT 8
- Feature: Automatically create/update records of child based on definition in parent or id in child
- Parameters do not work in string functions HOT 5
- Feature: Omit in fetch
- Feature: Live Query WHERE clause should process Params HOT 4
- Bug: Delr is displayed in trace logs of releases HOT 1
- Bug: I upgraded my server surreal version and lost all my data HOT 6
- Bug: OPTION IMPORT causes bugs with FTS indexes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from surrealdb.