Removing a label from Vertex - gremlin

Amazon Neptune supports multiple labels for a vertex. While I'm able to add a new label to vertex, I couldn't find a way to remove it.
I found out that
vertex.addLabel('human')
vertex.removeLabel('human')
http://tinkerpop.apache.org/docs/current/reference/#_multi_label
is not supported on AWS Neptune.
Also trying drop() labels like properties not working.
Neptune documentation says:
gremlin> g.addV('label1').property(id, 'customid')
gremlin> g.addV('label2').property(id, 'customid')
gremlin> g.V('customid').label()
==>label1::label2
But that way you can only add label nothing about the removal of the label.
I am looking for some way like removeLabel() to remove label without removing the vertex.

You will find this text in the Apache TinkerPop documentation at [1]
"This is because TinkerPop does not allow the vertex label to be changed after the vertex has been created."
The ability to change a vertex label after it is created is not allowed per the TinkerPop reference documentation and implementation. This as far as I know is honored by most if not all of the TinkerPop enabled Graph DBs.
The example you found is part of the custom support for Neo4J when connected directly (not via a Gremlin Server style of connection) where the vertex object can be directly manipulated.
If you need the concept of an editable label I would suggest using a property instead. The net result will be about the same in terms of looking up by property versus by label and a lot more portable.
[1] http://tinkerpop.apache.org/docs/current/reference/#_graphml_reader_writer

Related

Here API - Autosuggest requiring parameter not required (in the documentation)

I am trying to use the Autosuggest feature from Here API following this documentation: https://developer.here.com/documentation/geocoding-search-api/api-reference-swagger.html
The documentation says only the "q" parameter is required but I am doing the following query and getting the following error:
URL query: https://autosuggest.search.hereapi.com/v1/autosuggest?q=new+y&limit=5&lang=en-US&apiKey=xxx
Response:
{"status":400,"title":"Required parameter missing. One of mutual exclusive parameters 'at', 'in=circle', 'in=bbox' should be present","correlationId":"43ab125b-4f59-4255-8699-210e3acd053a","requestId":"REQ-aff498e0-ec75-45a9-998e-12b4ffa60d04"}
Am I missing something?
Thanks.
Yes, I have missed this part of the doc:
One of "at", "in=circle" or "in=bbox" is required.
I guess it is not shown explicitly as required (*) because it depends on two different fields.
In the previous API version (v6) this field is not required, I don't know why this is required now.
If someone needs a globally auto-suggesting it won't cover. Even if I can use a long radius covering the world but it looks not right as the field is required.

Gremlin Java replace old vertex properties with new property

I am trying to use gremlin java to replace some vertex's property like this:
graph.V(1).properties().drop().property("foo", "bar").iterate()
However, this only remove property but doesn't add new property.
I think iterate should probably be immediately after drop, but I am connecting to remote graph db so I wish to reduce query count.
Hope there is some way to achieve this:
graph.V(1).properties().drop().property("foo", "bar")
.V(2).properties().drop().property("foo", "bar").....iterate()
Yes, you can definitely do that, check out the live example: https://gremlify.com/27
You can select the vertex and see it's properties, or run g.V().valueMap(true) and afterwards:
g.V().sideEffect(properties ().drop()).property ("foo", "boo");
To see the new properties applied to it.
(For simplicity, I assumed a single vertex on the graph but this applies for any vertex).
The answer by #gremlify is correct. And alternatively you can use .union() command also.
g.V().union(
properties().drop(),
property('foo', 'boo')
);

choose and option steps in Cosmos DB gremlin API

Although choose is not on the list of supported gremlin steps for Cosmos DB (as well as some others) it seems to be supported. Given an example graph with people it a query like
g.V().hasLabel('person').choose(values('name'))
.option('josh', constant('it's Josh!'))
returns a json array ['Josh!']. Adding more option also works e.g.
g.V().hasLabel('person').choose(values('name'))
.option('josh', constant('it's Josh!'))
.option('marco', constant('it's marco!'))
but what doesnt seem to work is using Pick.none/ none for specifying a default case as described in the gremlin docs for choose e.g.
g.V().hasLabel('person').choose(values('name'))
.option('josh', constant('it's Josh!'))
.option('marco', constant('it's marco!'))
.option(none, constant('it's somebody else!'))
Does anybody know how to specify the default case in Cosmos DB? I already tried any permutation containing Pick and/or none that I could think of e.g. Pick.none, Pick().none(), none, none(), ...

aem-6-2-replication-issue-for-node-containing-invalid-jcr-names

I am working on AEM 5.6 to 6.2 upgrade project. There are some nodes in aem 5.6 environment which contains invalid character(as per JCR naming convention like rte[2] is one of the node name which doesn't follow the naming convention)but somehow we are able to replicate those nodes in 5.6 environment. After upgrade it to aem 6.2,it seems like JCR is more restricted and won't allow the nodes to replicate if it is having invalid characters.
Getting the below error in aem 6.2: error:
com.day.cq.replication.ReplicationException: Repository error during node import: Cannot create a new node using a name including an index
Is there any way we can configure AEM 6.2 to stop checking JCR node names?or any other solution?
JCR 2 does not allow [ as a valid character therefore you won't get an easy workaround for this. It's one of the limitations just like the same-named-sibling.
My recommendation will be to modify these nodes before the upgrade/migration to 6.2. This can be complicated and costly for business but 6.2 won't allow it.
As a background [ was allowed in older version due to twisted support for grammar syntax for same-named-siblings.
Assuming that these are all content nodes as nothing out-of-the-box in AEM 5.x follows this naming convention.
Some ways to fix it:
Write a custom servlet to query and rename the paths across all references. You will have to test your content for these renames.
Use Groovy console (https://github.com/OlsonDigital/aem-groovy-console) to rename the nodes.
In either case, you will need to modify the nodes before the migration as the structure is not oak compliant therefore you cannot use crx2oak commit hooks also. This can be done with both in-place upgrade and side-by-side migration. This is similar to the problem with same named siblings that must be corrected before the migration.
Some efficiency techniques that might help:
Write queries to find invalid node names on top-level nodes like /content/mysite-a, /content/mysite-b etc. Don't run root level queries on /content as it might downgrade to
traversal and halt the execution.
Ensure that all references are updated in same commit. If you are using custom servlet, call session.save() only after updating all the node names and it's corresponding references.
As i mention in the comment this replication failure causes because of the oak workspace restriction as the code snippet below
//handle index
if (oakName.contains("["))
{ throw new RepositoryException("Cannot create a new node using a name including an index");
}
and i feel you can't escape this constraint as it it required by the repository to maintain consistency
you can find nodes that ends with '[', by below query
SELECT [jcr:path] FROM [nt:base] WHERE ISDESCENDANTNODE('/content/path/') AND [jcr:path] like '%\['
and to modify the JCR/CRX nodes you can use CURL or SlingPostServlet method
Some helpful posts are blow.
https://github.com/paulrohrbeck/aem-links/blob/master/curl_cheatsheet.md
http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html
Can you try migrating using a tool like oak-upgrade and let us know if you are still facing this issue.
The tool is robust and you have the flexibility to configure specific sub-trees for migration using this tool.

How do you take advantage of a composite index restricted to a vertex label?

Suppose I have defined a composite index and vertex label like so:
mgmt = g.getManagementSystem()
name = mgmt.makePropertyKey('name').dataType(String.class).make()
god = mgmt.getVertexLabel('god')
mgmt.buildIndex('byName',Vertex.class).addKey(name).indexOnly(god).buildCompositeIndex()
mgmt.commit()
How do I take advantage of this index in Gremlin?
Assuming it is something like g.V('label','god').has('name','zeus'), which is more performant?
g.V('label','god').has('name','zeus')
g.V('name','zeus').has('label','god')
Traditionally we would go with (2) because name is more highly selective than label, but is there something special about vertex labels that makes this untrue?
Ok, you've already found out, that it's currently impossible in Gremlin and only available through the Query API. Regarding the performance: Your two approaches won't make a difference; under the hood both queries generate the same Cassandra/HBase query (or whatever storage backend you are using).
Cheers,
Daniel
It doesn't work yet in TP2, but will work with TP3 (Titan 0.9 / next release). Currently you can do this:
g.query().has('label','god').has('name','zeus').vertices()
No idea about the performance profile still.
https://github.com/thinkaurelius/titan/issues/755

Resources