Absent values in automatic composite SB-Tree index

[Severogor]

I'm working with OrientDB Enterprise Server v2.1.13 and have faced some problems I can't find explanation and solution for yet.

It seems that automatic composite SB-Tree index works improperly and doesn't index new values (or I misunderstand something). A have the following edge classes:

CREATE CLASS ACTION EXTENDS E CLUSTERS 0 ABSTRACT

CREATE PROPERTY ACTION.out LINK
  ALTER PROPERTY ACTION.out MANDATORY true
  ALTER PROPERTY ACTION.out NOTNULL true

CREATE PROPERTY ACTION.in LINK
  ALTER PROPERTY ACTION.in MANDATORY true
  ALTER PROPERTY ACTION.in NOTNULL true

CREATE PROPERTY ACTION.action STRING
  ALTER PROPERTY ACTION.action MANDATORY true

CREATE PROPERTY ACTION.status STRING
  ALTER PROPERTY ACTION.status DEFAULT 'NEW'

CREATE INDEX ACTION.out_action_in ON ACTION (out, action, in) UNIQUE

CREATE CLASS LINK EXTENDS ACTION CLUSTERS 8
  ALTER CLASS LINK CLUSTERSELECTION balanced

CREATE INDEX LINK.out_action_in ON LINK (out, action, in) UNIQUE

Suppose we have some vertices - with RIDs #12:0 and #30:0.
Then we do inserts:

CREATE EDGE LINK FROM #12:0 TO #30:0 SET action = 'a';

We can SELECT and see that it was inserted correctly into the database:

orientdb {db=data}> SELECT FROM LINK WHERE action = 'a';

----+-----+------+------+-----+-----+------
#   |@RID |@CLASS|action|out  |in   |status
----+-----+------+------+-----+-----+------
0   |#36:0|LINK  |a     |#12:0|#30:0|NEW   
----+-----+------+------+-----+-----+------

Now let's create SB-Tree NOTUNIQUE index (the default):

CREATE INDEX LINK.action_status ON LINK (action, status) NOTUNIQUE

Now we CREATE a new record:

orientdb {db=data}> CREATE EDGE LINK FROM #12:0 TO #30:0 SET action = 'b';
orientdb {db=data}> SELECT FROM LINK

----+-----+------+------+-----+-----+------
#   |@RID |@CLASS|action|out  |in   |status
----+-----+------+------+-----+-----+------
0   |#36:0|LINK  |a     |#12:0|#30:0|NEW   
1   |#37:8|LINK  |b     |#12:0|#30:0|NEW   
----+-----+------+------+-----+-----+------

Now we try to SELECT the 'a' and 'b' values:

orientdb {db=data}> SELECT FROM LINK WHERE action = 'a'; 

----+-----+------+------+-----+-----+------
#   |@RID |@CLASS|action|out  |in   |status
----+-----+------+------+-----+-----+------
0   |#36:0|LINK  |a     |#12:0|#30:0|NEW   
----+-----+------+------+-----+-----+------

1 item(s) found. Query executed in 0.001 sec(s).

orientdb {db=userdata}> SELECT FROM LINK WHERE action = 'b';

0 item(s) found. Query executed in 0.001 sec(s).

EXPLAIN:

Profiled command     '{fullySortedByIndex:false,compositeIndexUsed:1,involvedIndexes:[1],limit:-1,fetchingFromTargetElapsed:0,indexIsUsedInOrderBy:false,user:#5:0,elapsed:1.116033,resultType:collection,resultSize:0}' in 0,002000 sec(s):
{"@type":"d","@version":0,"fullySortedByIndex":false,"compositeIndexUsed":1,"involvedIndexes":["LINK.action_status"],"limit":-1,"fetchingFromTargetElapsed":0,"indexIsUsedInOrderBy":false,"user":"#5:0","elapsed":1.116033,"resultType":"collection","resultSize":0,"@fieldTypes":"compositeIndexUsed=l,involvedIndexes=e,fetchingFromTargetElapsed=l,user=x,elapsed=f"}

But -- if you SELECT it using IN() -- it's there (seems that the IN() operator doesn't use indexes anyway - another issue I've faced):

orientdb {db=data}> SELECT FROM LINK WHERE action in ['b'];

----+-----+------+------+-----+-----+------
#   |@RID |@CLASS|action|out  |in   |status
----+-----+------+------+-----+-----+------
0   |#37:7|LINK  |b     |#12:0|#30:0|NEW   
----+-----+------+------+-----+-----+------

1 item(s) found. Query executed in 0.002 sec(s).

EXPLAIN:

Profiled command '{documentReads:1,current:#36:1,documentAnalyzedCompatibleClass:1,recordReads:1,limit:-1,fetchingFromTargetElapsed:0,evaluated:1,user:#5:0,elapsed:0.666479,resultType:collection,resultSize:1}' in 0,002000 sec(s):
{"@type":"d","@version":0,"documentReads":1,"current":"#36:1","documentAnalyzedCompatibleClass":1,"recordReads":1,"limit":-1,"fetchingFromTargetElapsed":0,"evaluated":1,"user":"#5:0","elapsed":0.666479,"resultType":"collection","resultSize":1,"@fieldTypes":"documentReads=l,current=x,documentAnalyzedCompatibleClass=l,recordReads=l,fetchingFromTargetElapsed=l,evaluated=l,user=x,elapsed=f"}

Any suggestions on this?
Thanks in advance.

[andrii0lomakin]

Cause of big is following - default record value is assigned after index hook is called but not before so index miss this record. Assigned to @tglman .

[Severogor]

Seems that the problem was not in index type. The similar problem exists in Hash Index type too. Values appear only after index recreation.

[tglman]

hi,
I added a few test cases, for check the case, and all pass without problem, i think the issue is not strictly related to the default value.

@Laa the default value is set at the moment when you set a class on the ODocument, so far before the hook invoke.

bye

[andrii0lomakin]

@tglman I have couple of questions:

1. Did you reproduce case as user wrote in the console ?
2. If you reproduced user tests case, did you debug it ?

[tglman]

i noticed that was done a fix for make the init of default value at earlier, back-ported now 475c257

closing