In our particular use case, we find particular property values that occur
in multiple vertices. We then create new vertices for each such unique
property value, and connect the original vertex to this new vertex via a
new edge. This "promotes" the relationship between vertex and property to
one between two vertices. It is related to "join" logic in a relational
database.
We want to write something like this:
g.V().has(T.label, 'foo').as('fooV').values('bar').as('name').select('name')
.addV(local, 'bar', 'name')
.addInE('has-bar', 'fooV')
In the above example, we only want a single scalar value from the traverser
for addV, so we provide the property name 'name'.
If instead we want to pick up multiple values from the traverser, it would
be a Map, and we wouldn't have to provide the property name.
Also, we really want "ensure" logic here, so instead of the bare addV, we
would probably have a coalesce that would check if there is already a "bar"
vertex. However, that requires a "mid-traversal V" step, which we lack.
That means a second pass where we collect redundant "bar" vertices, and
replace them with one per unique "name" value.
On Tue, Jun 2, 2015 at 2:37 PM, Marko Rodriguez <[email protected]>
wrote:
> In, Graph.addVertex(Object…), those objects are key/value pairs, where
> objects.length % 2 == 0.
>
> Sorry if I'm being dense… can you keep explaining?
>
> Thanks,
> Marko.
>
> On Jun 2, 2015, at 3:34 PM, Ran Magen <[email protected]> wrote:
>
> > The vertices can be {{Object[]}} like in {{Graph.addVertex()}}.
> >
> > On יום ד׳, 3 ביוני 2015 at 00:31 Marko Rodriguez <[email protected]>
> > wrote:
> >
> >> Hello,
> >>
> >> I don't get it. You have vertices from one graph, and then you want
> >> "clone" them into another graph. ?
> >>
> >> Marko.
> >>
> >> http://markorodriguez.com
> >>
> >> On Jun 2, 2015, at 1:57 PM, Ran Magen <[email protected]> wrote:
> >>
> >>> I guess it would look something like this:
> >>> {{__.inject(vertices).as("x").addV("x")}}
> >>>
> >>> It does seem kind of a stretch to do this in a traversal, but it will
> >>> enable:
> >>> 1. Inserting vertices in bulk (see TINKERPOP3-701)
> >>> 2. {{EventStrategy}} and Validation strategies, which can't work with
> >>> {{Graph.addVertex()}}
> >>>
> >>> Maybe you can think of a better way to make those work.
> >>> On יום ג׳, 2 ביוני 2015 at 22:34 Marko A. Rodriguez (JIRA) <
> >> [email protected]>
> >>> wrote:
> >>>
> >>>>
> >>>> [
> >>>>
> >>
> https://issues.apache.org/jira/browse/TINKERPOP3-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569615#comment-14569615
> >>>> ]
> >>>>
> >>>> Marko A. Rodriguez commented on TINKERPOP3-694:
> >>>> -----------------------------------------------
> >>>>
> >>>> Uhh.. What would that look like?
> >>>>
> >>>>> Bulk loading in TP
> >>>>> ------------------
> >>>>>
> >>>>> Key: TINKERPOP3-694
> >>>>> URL:
> >>>> https://issues.apache.org/jira/browse/TINKERPOP3-694
> >>>>> Project: TinkerPop 3
> >>>>> Issue Type: Improvement
> >>>>> Components: process
> >>>>> Reporter: Ran Magen
> >>>>>
> >>>>> Bulk loading can greatly increase performance in many backends, but
> >>>> there is no way for vendors to implement bulk loading in the TP API.
> >>>>> As for how to do it, I was thinking a vendor could inherit from
> >>>> AddXStep, and implement bulk loading, enabling something like this:
> >>>>> ArrayList<Object[]> vertices;
> >>>>> __.inject(vertices).as("x").addV("x")
> >>>>> Pros:
> >>>>> 1. This seems like a standard approach to me, since vendors today
> batch
> >>>> up queries this way (
> >>>>
> >>
> https://github.com/thinkaurelius/titan/blob/titan09/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/tinkerpop/optimize/TitanVertexStep.java#L72
> >>>> )
> >>>>> 2. In contrast to the Graph.addVertex method (and the likes), using
> a
> >>>> traversal enables taking advantage of other strategies, like
> >> EventStrategy,
> >>>> a validation strategy, etc.
> >>>>> Cons:
> >>>>> 1. I don't think the mutating steps currently work with "x" (I'm not
> >>>> sure how you call this feature).
> >>>>> 2. The steps are marked as final.
> >>>>> Cheers,
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> This message was sent by Atlassian JIRA
> >>>> (v6.3.4#6332)
> >>>>
> >>
> >>
>
>
