Automatic List unfold with limit(local, 1)

[Peter Wong]

I ran into a surprising behavior (bug?) with limit(local, 1).

g.inject([1, 2, 3], [4]).limit(local, 3).toList() // [[1, 2, 3], [4]]
g.inject([1, 2, 3], [4]).limit(local, 2).toList() // [[1, 2], [4]]
g.inject([1, 2, 3], [4]).limit(local, 1).toList() // [1, 4] ??? - Expected [[1], [4]]

g.inject([1, 2, 3], [4]).limit(local, 0).toList() // [[], []] oh come on

https://gremlify.com/u2mh3dhllk

https://gremlify.com/u2mh3dhllk/1

https://gremlify.com/u2mh3dhllk/2

I hope others can appreciate how annoying/inefficient dealing with an inconsistent result structure is :) Either before querying (choose a different query depending on limit number) or after querying (correcting resulting structure).

Questions:

• Is this is expected behavior?
• If so...
  • Is there a different way of writing this, that yields a consistent result structure regardless of limit number (always an array of arrays)?
  • Is there an over arching rule that describes this "if-a-list-has-one-then-unfold" behavior?
  • Are there other "if one, do something different" behaving steps?

[Daniel C. Weber]

Hi,

This might help:  Enforcing a common type of elements in a stream filtered with limit(local) (google.com)  

Regards

Daniel

[Stephen Mallette]

Peter, This is a nice example set:

I ran into a surprising behavior (bug?) with limit(local, 1).

g.inject([1, 2, 3], [4]).limit(local, 3).toList() // [[1, 2, 3], [4]]
g.inject([1, 2, 3], [4]).limit(local, 2).toList() // [[1, 2], [4]]
g.inject([1, 2, 3], [4]).limit(local, 1).toList() // [1, 4] ??? - Expected [[1], [4]]

g.inject([1, 2, 3], [4]).limit(local, 0).toList() // [[], []] oh come on

I don't recall the design decision behind this at all, but from this perspective it looks weird and then Daniel brings up that link of insanity (not an easy thread) and without thinking too much into history of why this is like this I gotta wonder if irrespective of history, this should change to be more consistent. I assume the unwrapping for limit(local,1) was done out of convenience to downstream steps as the typical pattern would be to pop off the first object out of a list and then use it in the stream

g.inject([1, 2, 3], [4]).limit(local, 1).sum() 

Without that we would have to do:  

g.inject([1, 2, 3], [4]).limit(local, 1).unfold().sum()   

Not the worst thing, but I suppose the current interpretation from the Gremlin perspective is that limit(local, 1) means I want one object from the list and therefore it's not a List I want anymore, it's the single object inside the list. Perhaps that is too much magic. I might be in favor of changing this behavior to be more consistent, thus:

g.inject([1, 2, 3], [4]).limit(local, 3).toList() // [[1, 2, 3], [4]]
g.inject([1, 2, 3], [4]).limit(local, 2).toList() // [[1, 2], [4]]

g.inject([1, 2, 3], [4]).limit(local, 1).toList() // [[1], [4]] 

g.inject([1, 2, 3], [4]).limit(local, 0).toList() // [[], []]

but that's not a change to be made lightly as a change like that will make a lot of existing code misbehave. Happy to hear further thoughts on this matter.

. 

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gremlin-users/915b039a-8a32-464c-8490-d3b55521acean%40googlegroups.com.

[Stephen Mallette]

Tracking this issue here going forward:

https://issues.apache.org/jira/browse/TINKERPOP-2491

[Peter Wong]

Thanks for the responses and context, I fully grasp and appreciate a breaking change like this won't be easy/fast to make consistent.

Stephen, thanks for opening the ticket to be tracked. I like the idea mentioned in the ticket to leverage `withStrategy` to opt-out (or opt-in) of this more consistent result structure.

I'll work around this by changing the query based on the limit value.