Feature: Handle functions as part of FROM clause of Live Queries

[hysuki]

Original: Bug: vars parse error on ws query method when adding 'live'

Describe the bug

When I attempt to use 'live' queries with variables via the ws 'query' method, I encounter a parsing error.

Steps to reproduce

{
  "id": 2,
  "method": "query",
  "params": [
    "LIVE SELECT * FROM type::table($tb);",
    {
      "tb": "user"
    }
  ]
}

{
  "error": {
    "code": -32000,
    "message": "There was a problem with the database: Parse error: Failed to parse query at line 1 column 24 expected query to end\n  |\n1 | LIVE SELECT * FROM type::table($tb);\n  |                        ^ perhaps missing a semicolon on the previous statement?\n"
  },
  "id": 2
}

Expected behaviour

{
  "id": 2,
  "result": [
    {
      "result": "93d2e14b-3d1e-4bfd-977e-65c3d7c0c496",
      "status": "OK",
      "time": "6.815083ms"
    }
  ]
}

SurrealDB version

surrealdb-1.4.2

Contact Details

aside.hazle@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

[emmanuel-keller]

@phughk Not sure if this is related to parsing, livequeries, or websockets. Worth investigating

[DelSkayn]

This is probably a case of somewhat confusing syntax. In live select statements the FROM clause may, currently, only contain either a table name or a parameter. A function call like type::table is not allowed.

This should probably be changed, cause the parameter currently can't really be used correctly.
A workaround for now is to change the query to something like the following:

let $tb_type = type::table($tb);
LIVE SELECT * FROM $tb_type

[DelSkayn]

Maybe this bug should be more a feature request for allowing expressions in live select from clauses.

[hysuki]

@DelSkayn It's perfectly understood

Do I need to create a new issue that feature request about this?
or will add feature request label this?

[phughk]

Hi @hysuki , this was recently resolved and should be available in #3946 and the query parsing was resolved in an earlier fix.
Please can you confirm if this is still the case for you after upgrading to 1.5.0-beta1

[phughk]

@DelSkayn kindly explained the issue in more detail - I hadn't noticed it was a function call, which would be new syntax to support. I have changed the ticket from a bug to a feature, as this would have to be added. Thank you both!