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!
Related
/{db}/_all_docs response seems to have identical id and key value. What is the difference between the two? The key field is not documented anywhere.
At first glance id and key may seem redundant, however it makes sense when considering _all_docs. From the documentation:
Executes the built-in _all_docs view*, returning all of the documents
in the database. With the exception of the URL parameters (described
below), this endpoint works identically to any other view. Refer to
the view endpoint documentation for a complete description of the
available query parameters and the format of the returned data.
* emphasis mine
So _all_docs is a built-in view. Consider the view documentation. It is helpful to think of views as being composed of three fields
id
key
value
User designed views generally take shape as id = document._id with
key and value produced by the emit() function (via the map function).
For example, the following map function
function (doc) {
emit(doc.someField, doc.someValue);
}
generates the view id = doc._id, key = doc.someField, value = doc.someValue.
The data I have is of the form
{"event": {"custom": {"dimensions": [{"Id": ....}, {},...{}]}, ...},...}
The key that I need to index by is in the list. However, Cognitive Search does not seem to let me access the value within the list. Azure Cog. Search also fails to access any content from the list while trying to index.
Are there any solutions you can think?
Not sure how you're trying, but Azure Cognitive Search supports Complex types. Take a look in the following link:
https://learn.microsoft.com/en-us/azure/search/search-howto-complex-data-types
As an Alternative, you can project the internal dimensions (assuming they have a fixed number of dimensions) to fields in your index.
When using Indexers to import the data, key fields are limited to what can be expressed in a field mapping which has some support for mapping functions but wont allow you to select a value of an object in a collection. Your only options are to pre-process and transform the data (such as a query if this is coming from Cosmos DB, or azure function trigger if coming from blobs) or use a different field as the id and put the dimension id in another field that is queryable.
To make the data queryable you can use complex types or if the dimensions are always in the same ordinal you can use output field mappings to map it to a field by collection ordinal such as /document/event/custom/dimensions/1.
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.
I'm looking for a way to clone a vertex in a titan graph using groovy code.
What I want to do is to create a new vertex (let's call this vertex y) that contains exactly the same data as another vertex (lets call this vertex x).
Then I will create a relation to vertex x from vertex y and then delete the previous relation to vertex x.
I know how to get vertex x and how to create/delete relation and add a new vertex.
My only question is, is it possible to clone a vertex and if so, how can this be done using groovy?
Like this:
Thanks in advance!
Blueprints has helper methods to copy the property of one element to another: copyProperties
public static void copyProperties(Element from, Element to)
Copy the properties (key and value) from one element to another. The properties are preserved on the from element. ElementPropertiesRule that share the same key on the to element are overwritten.
Parameters:
from - the element to copy properties from
to - the element to copy properties to
Can't think of easier ways to do that offhand.
So far I haven't found any samples of HOW the elastic.js client api (https://github.com/fullscale/elastic.js) can be used for indexing documents. There are some clues here & there but nothing concrete yet.
http://docs.fullscale.co/elasticjs/ejs.Document.html
Document ( index, type, id ): Object used to create, replace, update, and delete documents
Document > doIndex(fnCallBack): Stores a document in the given index and type. If no id is set, one is created during indexing.
Document > source (doc): Sets the source document.
Can anyone provide a sample snippet of code to show how an document object can be instantiated and used to index data?
Thanks!
Update # 1 (Sun Apr 21st, 2013 on 12:58pm CDT)
https://gist.github.com/pulkitsinghal/5430444
Your gist is correct.
You create ejs.Document objects specifying the index, type, and optionally the id of the document you want indexed. If you don't specify an id, elasticsearch will generate one for you.
You set the source to the json object you want indexed then call the doIndex method specifying a callback if needed. The node example does not index docs, but the angular and jquery examples show a basic example and can easily be used with the node client.
https://github.com/fullscale/elastic.js/blob/master/examples/angular/js/controllers.js#L30
Also have a peek at the tests:
https://github.com/fullscale/elastic.js/blob/master/tests/index_test.js#L265
elastic.js nowadays only implements the Query DSL, so it can't be used for this scenario anymore. See this commit.