Bug: Unclear behavior for db.insert

[knackstedt]

Describe the bug

This may be an artifact of the (as I percieve it) ambiguous table name setup in the JS SDK of SurrealDB.
The documentation suggests using a colon followed by mathematical angle brackets to create a new object in a table with the contents of the mathematical brackets as the id.
However, all it does is declare a table and NOT insert a new record into said table.

If the functionality is meant to create a table with whatever the string contents are, that's fine but it needs to be documented in the JS SDK. It would also need to actually insert the object I pass in the same way as when I call the method with a simple ascii string that doesn't have any unusual characters.

Steps to reproduce

    await db.insert("foobar:123", { thing: true });
    await db.insert("foobar:guid()", { thing: true });
    await db.insert("foobar:⟨456⟩", { thing: true });
    
    
    await db.create(new RecordId('foobar', '789'), { thing: true });
    

    await db.insert("foobar", { id: "exact_id", thing: true });

Expected behaviour

Either behave the same way as the older versions where tables and string IDs can be parsed apart, or insert the record that is provided. If there's a third scenario where the SDK intends for developers to be able to create tables by theirselves and not insert a record, then throw an error when a developer provides the arguments in an inconsistent manner.

SurrealDB version

2.0.4 linux

JavaScript SDK version

1.0.6

Contact Details

[email protected]

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

[kearfy]

Hey @knackstedt, these are all actually valid table names, as table names when escaped with backticks or mathematical brackets can contain any complex character.

In hindsight, we should have stopped accepting strings for these methods, and only accept instances of Table, RecordId, RecordIdString and RecordIdRange to make this change more transparent, but since we already stabilised 1.0.0 this change can no longer be made. The only alternative I think would be to do another major release, but I'm not sure if that's the best solution 😅

I'll have some more discussions about this internally