[dITjfMpu] apoc.coll.indexOf unexpectedly treats collections differently than the same hardcoded list

[vga91]

Potentially this behaviour can affect a lot of procedures/functions, both apoc.coll and elsewhere.
I changed some of them, just to discuss about a possible solution that can be good for each procedure/fun that may have the problem.
For the other cases I created a follow-up card (id: v8imq7eo)

I think the possible solution are:

• Util.toAnyValues(..), as done in apoc.coll.toSet, which transform every object in AnyValue
  • pros: less code to change, just wrap the lists with that method
  • cons: tranform Object in AnyValue, so e.g an hardcoded [1,2,3] is converted from ArrayList to long[], so it could be considered a breaking change
• Create Util method that leverage ValueUtils.of(), as done in apoc.coll.indexOf and apoc.coll.containsAll
  • pros: no need to loop through lists to transform to AnyValue
  • cons: e.g with an apoc.coll.toSet(<NodePropValue>, ... <HardcodedValue>), if the two ..Value are equal, the function will return the nodeProp or the hardcoded based on which one finds first.

[gem-neo4j]

You could use the new COLLECT instead to make it more readable :) Also maybe multi line instead of having addition as that is also a little hard to read:

WITH COLLECT {
MATCH (n:Test)
RETURN {something: n.something}
ORDER BY n.a} + { something: []
} + {something: 'alpha'} + {something: [1,2,3]} AS collection
RETURN apoc.coll.indexOf(collection, { something: [] }) AS index

[vga91]

changed

[gem-neo4j]

If we are doing an ORDER BY (and change to using COLLECT subquery over function), then it should always be 1?

[gem-neo4j]

I also did a test on another apoc.coll proc:

WITH COLLECT { 
    MATCH (n:Test) 
    RETURN n.something
    ORDER BY n.a}  + [[]] + [[1,2,3]] AS collection
CALL apoc.coll.elements(collection) 
YIELD _1,  _1l,
      _2,  _2l,
      _3, _3l,
      _4,  _4l,
      _5,  _5l,
      _6, _6l
RETURN _1,  _1l,
       _2,   _2l,
       _3,   _3l,
      _4,  _4l,
      _5,  _5l,
      _6, _6l

And it also doesn't work (lists are returned as null if they are from the collect).

There are a lot of coll funcs and procs, but I guess it would make sense for all to be fixed for this issue?

[vga91]

I added the apoc.coll.elements array handling.
I think it's only a problem of that procedure, at least regarding the apoc.coll ones,
since the method I changed is only called by that function.
But potentially other pieces of code could have that problem,
so I'd create another follow-up card to investigate about that. Wdyt?

[vga91]

Or maybe, we can fix the apoc.coll.elements directly in the new follow-up card,
together with the research/fix about other analogous problems.

[gem-neo4j]

Yep, a new card is fine :)

[vga91]

Created the follow-up card (id: gtjPFvMD)

[gem-neo4j]

What is the \s here for?

[vga91]

It was just a whitespace which intellij had automatically added.
Removed :)

[gem-neo4j]

LGTM :)