Weird erroring behavior with params/sqlscript variables and `SELECT FROM`

[ExtReMLapin]

Hello, on release 25.5.1

We're trying to port some of our code from Cypher to SQLSCRIPT.

I have the following code that works when sent thru REST API :

LET $source = (SELECT FROM :__rid);
return $source

With params : {'__rid': '#1:143'}

It returns : [{'@rid': '#1:143', '@type': 'CHUNK', '@cat': 'v'}]

---

In studio I tried the following :

LET $source_id = '#1:143';
LET $source = (SELECT FROM $source_id);

RETURN [$source_id, $source]

"com.arcadedb.query.sql.executor.ExecutionStepInternal.syncPull(com.arcadedb.query.sql.executor.CommandContext, int)" because "this.lastStep" is null

---

LET $batch_in = [{'source_id': '#1:143', 'target_id': '#4:0', 'features': {}, 'relation_type': 'in'}];
LET $source = (SELECT FROM $batch_in[0].source_id);

RETURN [$batch_in[0].source_id, $source]

---

What the hell am I doing wrong ?

[gramian]

Hi,
AFAIK parameters and variables can/should only be used in "typed syntax", meaning anywhere a typed value, ie a string, integer etc would go, and not somewhere untyped syntax, ie, keywords, type names, etc are used. Your first example is a corner case, I guess; see first referenced issue below.

BTW: Issues #1625 and #1842 may be related.

[ExtReMLapin]

Well crap then, because i got a function that takes as input a batch of rid_in and rid_out, relation type and relation features dict to be created in batch.

Right now i'm dividing the batch into subbatches because as you mentionned, relation types cannot be "dynamic" in a loop.

[gramian]

Well, as a workaround how about something like:

LET $source_id = '#1:143';
LET $source = (SELECT FROM Type WHERE @rid = $source_id);

RETURN [$source_id, $source]

The filter argument can be a parameter or variable as it is typed (either RID or string).

[ExtReMLapin]

Yeah but type would have to be hardcoded aswell, and cannot be a variable.

I feel like going this way is going around a problem just to meet another one :(

[ExtReMLapin]

With cypher we don't have this issue (beside sub-batches for relation type) till you fall into a ScalaMatch error

[gramian]

In a way. On the other hand, allowing variables and parameters everywhere is probably a security nightmare.

A workaround for the type could be to add a property reflecting the type... I know; but a "table" name is metadata and not data.

[lvca]

1. In SelectExecutionPlanner.calculateTargetBuckets() (line 2569-2577): When resolving a variable in SELECT FROM $variable, the code was calling item.setValue(value) followed
   by item.setIdentifier(null). However, setValue() only handles Identifiable and ResultSet types - it didn't handle RID strings (like 'build support #1:143'). This left the FromItem in an
   invalid state with no identifier and no RIDs, causing handleFetchFromTarget() to throw UnsupportedOperationException.
2. In Rid(RID) constructor (line 46): The position was incorrectly set to rid.getBucketId() instead of rid.getPosition(), causing wrong RID values when converting RID objects
   to Rid parser nodes.

[lvca]

Fixed with the new SQL parser