Repository navigation
SQL on an edge: out and in silently return null (the endpoints are @out / @in); a docs line or an error would help #10684
Description
On an edge, SQL reads the endpoints as @out and @in (the docs use them throughout, e.g. CREATE INDEX ... (@out, @in) and WHERE @out = #12:0), and outV() / inV() work too. Plain out and in are not fields of an edge, but reading them is not an error: they return null, and so does every path through them. A query written the OrientDB way, or by someone who guesses the field name, silently returns nulls instead of failing.
Reproducer (ArcadeDB 26.10.2 through the Python bindings arcadedb-embedded 26.10.2.post1; the statements are plain SQL, so any client shows the same):
import arcadedb_embedded as arcadedb
with arcadedb.create_database("./t") as db:
db.command("sql", "CREATE VERTEX TYPE A"); db.command("sql", "CREATE VERTEX TYPE B"); db.command("sql", "CREATE EDGE TYPE E")
with db.transaction():
db.command("sql", "INSERT INTO A SET id = 1"); db.command("sql", "INSERT INTO B SET name = 'x'")
db.command("sql", "CREATE EDGE E FROM (SELECT FROM A) TO (SELECT FROM B) SET qty = 7")
for q in ("SELECT out.id FROM E", "SELECT in.name FROM E", "SELECT out FROM E", "SELECT @out.id FROM E", "SELECT outV().id FROM E"):
print(q, [r.to_dict() for r in db.query("sql", q)])| Query | Result |
|---|---|
SELECT out.id FROM E |
[{'out.id': None}] |
SELECT in.name FROM E |
[{'in.name': None}] |
SELECT out FROM E |
[{'out': None}] |
SELECT @out.id FROM E |
[{'@out.id': 1}] |
SELECT outV().id FROM E |
[{'outV().id': 1}] |
openCypher on the same data is fine (MATCH (a)-[r:E]->(b) RETURN a.id, b.name, r.qty returns 1, x, 7).
Expected: either a sentence in the SQL docs (edges / record attributes) saying that the endpoints of an edge are @out and @in, not out and in, or a warning or error when a query reads out or in on an edge type that has no such property. Not checked on main.
Activity
feat(#10684): SQL reads out / in on an edge as its endpoints (#10806)
tae898 commentedon Oct 27, 2026
Verified on current
main33e4747899(contains the fix #10806, merge2a205e8b5a) against1993631cad(before it), engine jars built from each commit, JDK 21 and JDK 25 (eclipse-temurincontainers), with the statements of this issue on the same data (vertexA {id: 1}, vertexB {name: 'x'}, edgeE {qty: 7}from A to B). Result of each query on JDK 21 (JDK 25 is identical):1993631cad33e4747899SELECT out.id FROM E[null][1]SELECT in.name FROM E[null][x]SELECT out FROM E[null][#1:0]SELECT in FROM E[null][#4:0]SELECT @out.id FROM E[1][1]SELECT outV().id FROM E[1][1]The same program also checks
WHERE out.id = 1 AND in.name = 'x',WHERE out = #1:0,WHERE out IS NULL,ORDER BY out,GROUP BY in.name, a path throughoutE('E').in.name, that an edge property namedoutstill wins, and that a vertex still answers null forout: 5 of 14 checks pass before the fix on JDK 21 (5 of 14 on JDK 25), 14 of 14 after it on both JDKs. The fix works as described in #10806.robfrank commentedon Oct 28, 2026
Fixed in #10806. On an edge without a property named
outorin, those names now resolve to the edge's endpoints exactly like@out/@in, instead of silently answering null. This is a behavior change: for exampleSELECT FROM E WHERE out IS NULLused to match edges without such a property and now matches none.Still open: #10807 (the planner's index/adjacency shortcut is not extended to
WHERE out = #rid; it is answered correctly by a scan, so performance only).❤️ Thanks for helping make ArcadeDB better! ArcadeDB is free and open source, sustained by its community. If it's useful to you or your company, please consider becoming a sponsor to keep development going.
Merge pull request #507 from tae898/docs/10684-edge-out-in
feat(#10684): SQL reads out / in on an edge as its endpoints (#10806)