orientechnologies / orientechnologies/orientdb

update with select subquery doesn't work with $parent.$current

Open
#9,761 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
5k
Forks
868
Avg merge
15h 6m
Merged PRs (30d)
18

Description

OrientDB Version: 3.1.9
Java Version: openjdk-8
OS: DockerFile FROM orientdb:3.1.9 (Debian GNU/Linux 10)

Expected behavior

I expect that:

update morph set uLevel = (select uLevel from nvdb where stem = 'ossia' and simpleType = 'conj') where simpleType = 'C' and stem = 'ossia';

and

update morph set uLevel = (select uLevel from nvdb where stem = $parent.$current.stem and simpleType = 'conj') where simpleType = 'C' and stem = 'ossia';

produce the same result (since the where in the update fixes the stem to the same value).
At least, unless I misunderstood $parent.$current or something changed between versions and I missed it.

Actual behavior

update morph set uLevel = (select uLevel from nvdb where stem = 'ossia' and simpleType = 'conj') where simpleType = 'C' and stem = 'ossia';

updates 1 record and uLevel value is 2 (as expected)

update morph set uLevel = (select uLevel from nvdb where stem = $parent.$current.stem and simpleType = 'conj') where simpleType = 'C' and stem = 'ossia';

updates 1 record, but uLevel value is null

Steps to reproduce

Well, I hope the above is sufficient, but let me know

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the two UPDATE statements from the issue against OrientDB 3.1.9 using the documented Docker environment, then inspect the SQL update and subquery handling involved in $parent.$current resolution. Done means the correlated subquery produces the expected uLevel value rather than null, with regression coverage for the reported statements.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql
Domain
databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.