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+...@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.w...@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.w...@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+...@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.w...@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+...@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.w...@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- > requ...@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- > requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev