As can be seen in this post (How can I add a node type to the graph from within a script in booggie 2?) it's possible to add nodes/edges to the metamodel in booggie and change their attributes.
Is it also possible to change the attributes of already existing nodes (or edges) in a graph using a script?
I think you can get all nodes/edges of the current graph using the Nodes and Edges properties.
Try this out:
edgeList = graph.Edges
nodeList = graph.Nodes
Afterwards you can iterate over these lists for node in nodeList: and sort out the elements having the attributes you wanna change, e.g. if node.myAttribute == 42:.
Related
I'm doing some testing to make sure that table data is rendered correctly in a table and in the right positions.
const tableRows = screen.getAllByRole("row");
expect(tableRows).toHaveLength(2); // Header plus one data row.
// Column 1 is a toggle icon.
expect(tableRows[1].querySelector("td:nth-child(2)").textContent).toBe("Hello");
expect(tableRows[1].querySelector("td:nth-child(3)").textContent).toBe("3 days ago");
expect(tableRows[1].querySelector("td:nth-child(4)").textContent).toBe("Success");
expect(tableRows[1].querySelector("td:nth-child(5)").textContent).toBe("EditDelete"); // Edit and Delete buttons.
However, es-lint is rightly complaining that I am using node access patterns via
Avoid direct Node access. Prefer using the methods from Testing Library. eslint(testing-library/no-node-access)
What's the best way to access nodes in this way?
Es-lint has some rules about this defined here
Depending on your render function, using Within may be an option for you. But for complex examples such as this we can make use of data-testid.
In the render function in the component, for each tableRow, you could add an attribute for data-testid and then access this element in the test through queryByTestId:
e.g. expect(screen.queryByTestId("table-row-2").textContent).toBe("Hello");
I have an existing tree and I would like to add anytree functionality by adding NodeMixin. The problem is that NodeMixin wants a fixed name 'children' for its sub-elements and I already have a list with a different name.
Another problem (I am using mypy) is that the exiting sub-elements list is not optional - terminal nodes have empty lists and NodeMixin wants 'None' as 'children' of terminal objects.
It will create a lot of changes if I have to rename the object and to deal with the optional nature of the children.
Is it possible to define children as #property or as a reference of the existing sub-elements?
(a) it is possible to use properties for parent and children, (b) it was easy to write custom iterable class for children to account for differences between anytree and my tree iterations.
Update: is_leaf property has to be overridden too - otherwise it will be true for every node.
i use the arangodb tinkerpop provider (https://github.com/ArangoDB-Community/arangodb-tinkerpop-provider) and create a vertex like this:
graph = GraphFactory.open(conf);
GraphTraversalSource g = gts.clone();
UUID userId1 = UUID.randomUUID();
Vertex vertex1 = graph.addVertex("person");
vertex1.property("uid", userId1);
Everything works fine and i see that i can found my starting vertex with this gremlin query:
System.out.println(g.V().has("uid", userId1).properties().toList());
Now, i've two questions:
1) Are all vertex properties searchable via an index or can i create an index especially for this property ?
2) inside the collections (Web UI from ArangoDb) i didn't see my properties - to see the properties, i need to look into *_ELEMENT-PROPERTIES - is there an other possibility to see the properties inside the collections view ?
Thanks for you help.
Marcel
I will answer question 2 first as this will help me address question 1.
2) Conceptually, the Tinkerpop API considers vertex properties (and vertex properties' properties) as graph vertices. As a result, the API expects vertex properties to behave like vertices and the navigation from a vertex to each of its properties to mimic that of two vertices connected by and edge:
v1 ---> uuid
where the uuid vertex would hold the uuid value. For this reason, the current implementation does NOT store the vertex properties in the vertex's document, but in a separate document (in the *_ELEMENT-PROPERTIES collection). The main drive for this approach is that it simplified the implementation a lot. One of the drawbacks is that, as you mentioned, looking at the properties of a vertex in the UI is not straight forward: you would need a query, instead of just opening a the vertex's document. BTW, the query you can use for this is:
WITH ##vertexlabel
FOR v, e
IN OUTBOUND #startrVertexID
##propertiesEdge
RETURN {"name": v.key, "value": v.value}
where you can provide the desired vertex label/collection, the vertex of interest ID and the appropriate propertiesEdge collection name (i.e. *_ELEMENT-PROPERTIES).
1) The current implementation does not allow providing indexes for specific attributes since properties are stored as documents and hence we can not use them as indices. As camba1 mentioned, ArangoDB automatically indexes _key in documents so you can use custom key values if you want to make sure searches based on a specific attribute are index based. Custom _key values are used by providing custom IDs. Note that the arangodb-tinkerpop-provider only supports custom vertex/edge/property IDs of type string (with some caveats). Thus, in your case you could use the UUID as the vertex's ID:
graph = GraphFactory.open(conf);
GraphTraversalSource g = gts.clone();
UUID userId1 = UUID.randomUUID();
Vertex vertex1 = graph.addVertex("person").properties(T.id, userId1.toString());
And then you can find this vertex by ID (which will be indexed);
System.out.println(g.V("*_vertex/" + userId1).properties().toList());
(Note that you need to replace * with our graph name.)
There is currently a bug opened for changing the storage of properties: Issue 38 and I have started work on a possible solution for which you can find details in the bug comments. Please feel free to chip in with any ideas!
Thanks for using the provider!
When creating graphs for viewing in the ArangoDB Web Interface, I am having some issues with labels for Vertices and Edges:
I can only set Vertex/Edge attributes to simple keys. I cannot get deeper object references working.e.g. a vertex label attribute of name is valid, but info.firstName or info["firstName"] are not, even though the value is on the vertex. The graph displays ATTR NOT SET if I use object references
When programmatically creating a Graph, I don't know how to set:
Vertices labels
Vertices Coloring attributes
Edge Labels
When creating a graph with Node.js and the arangojs npm package, I use the graph.create command, for example:
var graph = db.graph('myGraph');
graph.create({
edgeDefinitions: [
{
collection: 'myEdges',
from: [
'myNodes'
],
to: [
'myNodes'
]
}
]
})
Is there a way to fully configure the graph for proper formatting in the ArangoDB Web Interface? I can't seem to find any other function in the libraries that would let me do this.
I destroy and recreate graphs all the time and it would be great to fully create a configured graph, referencing objects within the vertex (and edges) for labels.
Thanks
Curerntly the settings of the graph viewer are only stored to the browsers local storage. Thus they're not persisted. Changing this is on the list of feature requests for the graph viewer overhaul.
So at the time being the answer is: its not possible. I will add the deep object selection you mention to the feature list. Once its possible, I will edit this.
This relates mostly with what a "best practice" would be with D3.js. I want to attach arbitrary information to different svg elements that I have on a page, after they are created. In D3, it looks like one generally generates svg elements from a dataset. I want to attach data to these svg elements at any time, without adding their HTML attributes.
Is there a good way of doing this? Do I need to use an auxillary array/object or is there a way to apply data to the elements themselves?
You would use the datum method if you want to attach arbitrary data:
D3.select('#mynodeId').datum( mydata );
And then later you could access the value again:
var mydata = D3.select('#mynodeId').datum();
Internally, D3 is going to use the __data__ property of the node, just like it does when the nodes were created from a data set via the selectAll, enter, append sequence.
Note that if you already have a reference to a DOM node you can pass it as the parameter to D3.select rather than making it re-look-up based on selector syntax:
D3.select( anExistingDOMNodeReference ).datum( mydata );
From the API doc:
d3.select(node): Selects the specified node. This is useful if you already have a reference to a node, such as d3.select(this) within an event listener, or a global such as document.body.