You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dbConn.Query("UPDATE my_table SET flag = false WHERE some_int = 10", map[string]interface{}{}) works fine.
But
dbConn.Query("UPDATE my_table SET flag = false WHERE some_int >= 10", map[string]interface{}{})
dbConn.Query("UPDATE my_table SET flag = false WHERE some_int <= 10", map[string]interface{}{})
dbConn.Query("UPDATE my_table SET flag = false WHERE some_int > 10", map[string]interface{}{})
dbConn.Query("UPDATE my_table SET flag = false WHERE some_int < 10", map[string]interface{}{})
are all hanging until GoLang client terminates them after about 240 seconds of waiting.
Similar issues happen with SELECT queries. Comparing with integers using = is ok, comparing with inequality operators never works. It doesn't matter whether the argument is passed directly or mapped through the second param of Query().
Steps to reproduce
Run SurrealDB server 2.0.3, connect to it using the GoLang library, select namespace and database with Use(), and try to run the queries above on a non-existent table
Expected behaviour
I expected that all of the queries will successfully return in about no time, taking into account that they were all executed on a non-existing table
Describe the bug
dbConn.Query("UPDATE my_table SET flag = false WHERE some_int = 10", map[string]interface{}{})
works fine.But
are all hanging until GoLang client terminates them after about 240 seconds of waiting.
Similar issues happen with
SELECT
queries. Comparing with integers using=
is ok, comparing with inequality operators never works. It doesn't matter whether the argument is passed directly or mapped through the second param ofQuery()
.Steps to reproduce
Run SurrealDB server 2.0.3, connect to it using the GoLang library, select namespace and database with
Use()
, and try to run the queries above on a non-existent tableExpected behaviour
I expected that all of the queries will successfully return in about no time, taking into account that they were all executed on a non-existing table
SurrealDB version
2.0.4 for linux on x86_64
Contact Details
[email protected]
Is there an existing issue for this?
Code of Conduct
The text was updated successfully, but these errors were encountered: