MATCHES broken in 2.1-rc3: fails to return data in simple query; causes Exception in nested query #4233
Comments
|
looks like 'matches' itself is broken... orientdb {db=testdb}> select from ItemMetadata
----+-----+------------+----------+-----------
# |@RID |@CLASS |code |in_metadata
----+-----+------------+----------+-----------
0 |#74:0|ItemMetadata|A-B-15-0-0|[size=1]
1 |#74:1|ItemMetadata|A-B-15-1-0|[size=1]
----+-----+------------+----------+-----------
2 item(s) found. Query executed in 0.012 sec(s).
orientdb {db=testdb}> select from ItemMetadata where code matches 'A-B.*'
0 item(s) found. Query executed in 0.007 sec(s).
and also this: orientdb {db=testdb}> select from ItemMetadata where code matches '*'
Error: com.orientechnologies.orient.core.sql.OCommandSQLParsingException: Error on parsing command at position #0: Encountered "" at line 1, column 32.
Was expecting one of:
orientdb {db=testdb}> select from ItemMetadata where code matches '.'
Error: com.orientechnologies.orient.core.sql.OCommandSQLParsingException: Error on parsing command at position #0: Encountered "" at line 1, column 32.
Was expecting one of:
using double quotes instead of single quotes does not cause the parser to fail, but still does not return the correct results: orientdb {db=testdb}> select from ItemMetadata where code matches "*"
0 item(s) found. Query executed in 0.015 sec(s).
orientdb {db=testdb}> select from ItemMetadata where code matches "."
0 item(s) found. Query executed in 0.006 sec(s). |
|
by the way, @buzzkillington, your original query would not have returned the right results anyway, since 'code' is a field of Item, not ItemMetadata which is the target of your query. orientdb {db=testdb}> select expand(in('metadata')) from (select from ItemMetadata where code='A-B-15-1-0')
----+-----+------+------+------------
# |@RID |@CLASS|name |out_metadata
----+-----+------+------+------------
0 |#73:1|Item |item 2|[size=1]
----+-----+------+------+------------
1 item(s) found. Query executed in 0.008 sec(s). |
|
@nagarajasr The original query is correct, "code" is a field of ItemMetadata (not Item) - see the examples I'd included for '='. Yours just moves the expand outside of the nested query, which happens to give the same result in this test, but (as I'd already mentioned) this is a simplified version of an existing query that worked in 2.0.x and I need it working again as-specified. Please keep the discussion relevant to the actual issue. |
|
Confirming that MATCHES is not working: |
|
For the nested query case, using the Java API for a prepared statement version of the query (with named parameters) results in the following stacktrace: |
|
thank you for reporting, I could reproduce the original problem, it's scheduled for a fix. thanks Luigi |
|
@luigidellaquila Certainly - here's the prepared statement code, as requested: |
|
MATCHES is also broken in non-nested statements (tested in console and studio) OrientDB2.1-rc3: SELECT FROM OUSER WHERE any() MATCHES '.*' OrientDB2.0: SELECT FROM OUSER WHERE any() MATCHES '.*' |
|
fixed in develop branch |
|
@luigidellaquila I just downloaded the rc5 (latest) download of orientdb and MATCHES still doesn't work. Am I missing something? |
Orient 2.1-rc3 throws an error when attempting to use MATCHES in a nested query. The following sample query/test works in 2.0.x, but fails with an error in 2.1-rc3. (Note: this example is a simplified version of the actual query that's failing in the application.)
Test steps to reproduce error in console:
Further check to verify equality works while matches fails:
The text was updated successfully, but these errors were encountered: