This might have been a false alarm. I think the current logic exhibited by TinkerGraph is the right way and we do have a test in the Structure suite that enforces it. I didn't see it there when I first looked as it is in a bit of an odd place: StarGraphTest. I will add a process test to help enforce it there as I think traversal strategies can be used to subvert the structure API sometimes.
On Thu, Oct 26, 2017 at 9:55 AM, Robert Dale <[email protected]> wrote: > Maybe outE() and inE() should only return non-self-referencing edges. Then > there should be a new step called selfE(). And every time it's called, it > posts a picture of Gremlin holding that edge to Facebook. :-) > > Hmm.. it seems like you made the engineering case. What's the user > perspective? I don't know. I don't use self-referencing edges. I think > logically it would return what I expected. But then again, I don't think > like most users. Why would a user expect or even want it to show up only > once? So a user would expect bothE() to return the set of inE and outE > edges (unique) not the union of inE,outE? I could see that. I'm not > against it. Just need to make sure that's clearly documented. > > > > Robert Dale > > On Thu, Oct 26, 2017 at 9:32 AM, Daniel Kuppitz <[email protected]> wrote: > > > Well, if you want to get it duplicated, you can just do union(outE(), > > inE()), > > that's easy and inexpensive. However, any way to get rid of the > duplicates > > can be expensive: > > > > - local(bothE().dedup()) // needs > to > > keep track of all edges; requires internal memory structures > > - union(outE(), __.as("a").inE().not(where(outV().as("a")))) // > enables > > partial path tracking; again that requires internal memory structures > > > > If we / providers implement the deduplication though, we wouldn't require > > any extra memory structures. Returning the duplicates makes sense to me > > from an engineering perspective, but not from a user perspective. > > > > Cheers, > > Daniel > > > > > > On Wed, Oct 25, 2017 at 6:53 PM, Robert Dale <[email protected]> wrote: > > > > > I think that bothE() == union(outE(),inE()) and outE().count() + > > > inE().count() == bothE().count(). If you don't want the > self-referencing > > > edge to be returned twice, then either make it a unidirected edge (if > > > supported) so that it would still satisfy the two previous condition or > > > dedup(). In either case, it's left to the user to determine what edges > > are > > > returned. > > > > > > Also, I think it makes sense that g.E() == g.V().outE(). It should not > > be > > > g.V().inE() due to potential for unidirected edges. > > > > > > > > > Robert Dale > > > > > > On Wed, Oct 25, 2017 at 9:32 AM, Daniel Kuppitz <[email protected]> > wrote: > > > > > > > IMO it should return the edge only once. > > > > > > > > Cheers, > > > > Daniel > > > > > > > > > > > > On Wed, Oct 25, 2017 at 5:47 AM, Stephen Mallette < > > [email protected]> > > > > wrote: > > > > > > > > > The test suite doesn't seem to enforce behavior related to > > > self-relating > > > > > edges. TinkerGraph does this: > > > > > > > > > > gremlin> g = TinkerGraph.open().traversal() > > > > > ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard] > > > > > gremlin> g.addV().as('a').addE('self').to('a') > > > > > ==>e[1][0-self->0] > > > > > gremlin> g.E() > > > > > ==>e[1][0-self->0] > > > > > gremlin> g.V().bothE().count() > > > > > ==>2 > > > > > > > > > > Should bothE() return 2 in this case or 1? I think that we've said > in > > > the > > > > > past that g.E() is the same as g.V().outE() or g.V().inE(), but not > > > > > necessarily g.V().bothE(). Thoughts? > > > > > > > > > > > > > > >
