Open Stack

I see, you want 2 edges between PC_a and PC_b.

In order to model such a use case you need to use the action update_relationship in the processor.

You can it in the following way:
   1. in the transformer create PC_a -> PC_b in the regular way, by using the action create_entity or update_entity.
   2. when a new relationship arrives, that should arrive with a new label you can model the transformer to return an action update_relationship and thus a new edge will be added between those entities.

Hope it helps,
Alexey

From: Yujun Zhang [mailto:zhangyujun+zte at gmail.com] 
Sent: Tuesday, January 10, 2017 7:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU]Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex

Great! So let's come back to my original question on redundant link.

Before: PC_a is connected to PC_b with Cable
After: PC_a is connected to PC_b with Cable AND Wi-Fi

How to we model this? 
1. Create a new edge labeled "Cable and Wi-Fi" ? 
2. Assign a structured label like ["Cable", "Wi-Fi"] to the edge?
3. Create two edges, one labeled "Cable", the other labeled "Wi-Fi"?
--
Yujun

On Mon, Jan 9, 2017 at 6:44 PM Weyl, Alexey (Nokia - IL) <alexey.weyl at nokia.com> wrote:
Hi Yujun,

After some more checks, I found out the current code will handle your case as well, because it will go into the 2.c.1.

Alexey

> -----Original Message-----
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.weyl at nokia.com]
> Sent: Monday, January 09, 2017 10:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex
>
> What will happen is the following:
> We have a connection between PC_a and PC_b with label Cable.
> Now a new event arrives and the transformer builds the following trio:
> (Vertex_A, Neighbors((Vertex_B, Edge), UPDATE) This transformed data
> arrives to the processor that goes to the UPDATE action:
> 1. Updates the Vertex_A (PC_a) properties in the graph.
> 2. Calls the _update_neighbors method:
>    a. finds all the valid_edges and the obsolete_edges
>    b. deletes all the obsolete edges from the graph
>    c. connects the valid edges to the graph:
>       iterates over all the neighbors, and for each neighbor checks:
>       1. if the neighbor_vertex doesn't exist yet or if the is_deleted
> property of the neighbor_vertex is false then:
>          a. Update this vertex in the graph.
>          b. check if the edge doesn't exist yet and if so then add the
> edge.
>
> In your case the edge the edge 'Cable' will be deleted from the graph
> because it is obsolete, but from what I see at the moment and can be
> seen in the code, it won't enter the to the 2.c.1 because the neighbor
> vertex already exists and the neighbor vertex isn't defined as
> is_delete=false.
>
> That is a problem, and I have a solution for the problem, which I need
> to make sure that it ruin anything else because everything goes through
> the processor.
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+zte at gmail.com]
> Sent: Monday, January 09, 2017 10:26 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU][vitrage]how touseplaceholder vertex
>
> Thanks Alexey. Could you explain a bit more detail based on the example
> in comments below?
>
> On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL)
> <alexey.weyl at nokia.com> wrote:
> That’s not what I mean.
>
> When some data is changed in a some vertices, their event is pushed to
> the event queue, and thus the correct transformer is called.
> We update the data of the current vertex, and for each neighbor that we
> created in the transformer, we check the following:
> if the neighbor vertex doesn't exist yet or if the id_deleted property
> of the neighbor vertex is false, then update the vertex in the graph.
> Then it checks if the edge is not in the graph yet, then it adds it.
>
> Before: PC_a is linked to PC_b with Cable
> After: PC_a is linked to PC_b with Wi-Fi
>
> So this will results in a removal of original edge (labeled Cable) and
> adding of new edge (labeled Wi-Fi) . Is that correct?
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+zte at gmail.com]
> Sent: Sunday, January 08, 2017 5:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> [vitrage]how touseplaceholder vertex
>
> Hi, Alexey
> On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL)
> <alexey.weyl at nokia.com> wrote:
> Hi Yujun,
>
> A relationship is defined by the following trio: source id, target id
> and a label on the edge.
> In the processor, I add only edges that doesn't exists.
>
> Currently the vertex is mapping to entity, and the edge is mapping to
> relationship.
>
> So do you mean that we should update the label if the relationship
> between two entities changes? e.g. we change the link between two PC's
> from cable to Wi-Fi.
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev