CMIS Relationships --> List of objects (documents or folder) by type of relationship - relationship

Good Morning.
I have several types of relationships created in a custom model.
Using CMIS, is there any way to search for associations by type? In order to get all the source or target documents or folders that use this association?
I evaluated the use of query in CMIS, in order to obtain the ids of the documents, but it is not possible to use query in relationships, (if I understand well).
For example, I have 4 processes A; B, C and D, which has several documents associated each.
Process A ----> type of relationship ---> sc.fatura
Process B ----> type of relationship ---> sc.contrato
Process C ----> type of relationship ---> sc.acta
Process D ----> type of relationship ---> sc.fatura
When searching for a contract, you would get all the documents associated with Process B. when you searched for sc.fatura, you would get all the documents in process A and D.
Is it possible to do something similar using CMIS?
Thanks for the help

Normally, when filtering results you'd try to use an OperationContext. I thought there might be a way to tell the OC to filter to a specific relationship type, but it does not look like it. So I think the best you can do is filter it yourself by checking the relationship's type ID, like this:
Session session = getSession();
// Dump the object's associations
OperationContext oc = new OperationContextImpl();
oc.setIncludeRelationships(IncludeRelationships.SOURCE);
Document sourceDoc = (Document) session.getObject(session.createObjectId(sourceObjectId), oc);
List<Relationship> relList = sourceDoc.getRelationships();
System.out.println("Associations of objectId: " + sourceObjectId);
for (Relationship rel : relList) {
// In this example I only want relationships of type sc:exampleRel1
if ("R:sc:exampleRel1".equals(rel.getRelationshipType().getId())) {
System.out.println(" " + rel.getTarget().getId());
}
}

Related

Neo4j query without specifying relation type

I have a graph representation of data with multiple nodes with random relationships
I'm using Neo4j to represent this and using query
Using query
MATCH (a)-[r]->(b)-[r2]->(c)
I'm getting an output where ever A is related with B and B is related with C
But I need to query nodes A and B with any relationship (call as RelationA) and all C following B (with RelationA) with the Same relation as A and B like the following image
if A is connected with more than one B then the expected graph will be like this
You can check the equality of the relationships in the WHERE clause.
MATCH path=(a)-[r]->(b)-[r2]->(c)
WHERE type(r)=type(r2)
RETURN path
P.S.: If you are viewing this result in the Neo4j browser, then it "connects the result nodes" which means it adds extra relationships between nodes that don’t match the criteria. Don’t forget to uncheck the "connect result nodes" option in the from the settings.

CYPHER, NEO4J Returning couples of nodes that are connected by a relationship of type A and not by a relation of type B

I am working on the Neo4j tutorial Movies database.
I would like to make a query that returns the people that directed a movie but did not produced it.
In order to accomplish this I have used the query:
match (m:Movie)<-[:DIRECTED]-(p:Person)-[r]->(m) where type(r) <> 'PRODUCED' return p
Nevertheless, if I make it return * I still get these couples (person, movie) where the person not only directed and produced the film but also wrote it:
In the image there is one of the not admissible couples that are returned by my query
On the contrary, the query seems to successfully rule out all those couples that are with only the two relationships 'PRODUCED' and 'DIRECTED'.
Is there a way of writing this query so that I can rule out all these couples as well?
You can use path pattern in WHERE:
match (m:Movie)<-[r:DIRECTED]-(p:Person)
where not (p)-[:PRODUCED]->(m)
return m, p, r

Arangodb update properties depend on edge type

I am trying to use AQL to update the whole node collection , named Nodes, depend on the type of edges they have
.
Requirement:
Basically, if 2 entity in Nodes has relation type= "Same", they would be updated with unique groupid properties (same for more than 2)
This would only run one time in the beginning (to populate groupid)
My concept approach:
Use AQL
For each entity inside Node, query out all connectable nodes with type=SAME
Generate an groupid and Update all of them
Write to an lookup object those id
For next entity, do a lookup, skip the entity if their id is there.
What I tried
FOR v,e,p
In 1..10
ANY v
EntityRelationTest
OPTIONS {uniqueVertices:"global",bfs:true}
FILTER p.edges[*].relationType[0]== "EQUALS"
UPDATE v WITH { typeName2:"test1"} IN EntityTest
return NEW
But I am quite new to arangodb AQL, is something like above possible?
In the end, what I use is a customize traversal object running directly inside Foxx in order to get the best of both world: performance and correctness. It seemed that we cannot do the above with only AQL

Composite or FilterPredicate query on Ref'd entity

Here's what I have:
class A{
Ref<foo> b;
Ref<foo> c;
int code;
Date timestamp
}
The pseudo "where" clause of the SQL statement would like like this:
where b = object or (c = object and code = 1) order by timestamp
In plain English, give me all the records of A if b equals the specific object or if c equals the specified object when code equals 1. Order the result w/ timestamp.
Is the composite query part even possible w/ datastore (Objectify)? I really don't want to do two queries and merge the results, because I have to sort by timestamp.
Any help is appreciated.
P.S. I already tried
new FilterPredicate(b, EQUAL, object)
This didn't work, because the entity type is not a support type.
Thanks!
Pass a native datastore Key object to the FilterPredicate. The Google SDK Key, not the generic Objectify Key<?>.
Normally when filtering on properties, Objectify translates Ref<?> and Key<?> objects to native datastore keys for you. With the google-supplied FilterPredicate, that isn't an option. So you have to do the translation manually.
Objectify stores all Key<?> and Ref<?> fields and native datastore Keys, so you can freely interchange them (or even change the type of fields if you want).

What is an appropriate data structure and database schema to store logic rules?

Preface: I don't have experience with rules engines, building rules, modeling rules, implementing data structures for rules, or whatnot. Therefore, I don't know what I'm doing or if what I attempted below is way off base.
I'm trying to figure out how to store and process the following hypothetical scenario. To simplify my problem, say that I have a type of game where a user purchases an object, where there could be 1000's of possible objects, and the objects must be purchased in a specified sequence and only in certain groups. For example, say I'm the user and I want to purchase object F. Before I can purchase object F, I must have previously purchased object A OR (B AND C). I cannot buy F and A at the same time, nor F and B,C. They must be in the sequence the rule specifies. A first, then F later. Or, B,C first, then F later. I'm not concerned right now with the span of time between purchases, or any other characteristics of the user, just that they are the correct sequence for now.
What is the best way to store this information for potentially thousands of objects that allows me to read in the rules for the object being purchased, and then check it against the user's previous purchase history?
I've attempted this, but I'm stuck at trying to implement the groupings such as A OR (B AND C). I would like to store the rules in a database where I have these tables:
Objects
(ID(int),Description(char))
ObjectPurchRules
(ObjectID(int),ReqirementObjectID(int),OperatorRule(char),Sequence(int))
But obviously as you process through the results, without the grouping, you get the wrong answer. I would like to avoid excessive string parsing if possible :). One object could have an unknown number of previous required purchases. SQL or psuedocode snippets for processing the rules would be appreciated. :)
It seems like your problem breaks down to testing whether a particular condition has been satisfied.
You will have compound conditions.
So given a table of items:
ID_Item Description
----------------------
1 A
2 B
3 C
4 F
and given a table of possible actions:
ID_Action VerbID ItemID ConditionID
----------------------------------------
1 BUY 4 1
We construct a table of conditions:
ID_Condition VerbA ObjectA_ID Boolean VerbB ObjectB_ID
---------------------------------------------------------------------
1 OWNS 1 OR MEETS_CONDITION 2
2 OWNS 2 AND OWNS 3
So OWNS means the id is a key to the Items table, and MEETS_CONDITION means that the id is a key to the Conditions table.
This isn't meant to restrict you. You can add other tables with quests or whatever, and add extra verbs to tell you where to look. Or, just put quests into your Items table when you complete them, and then interpret a completed quest as owning a particular badge. Then you can handle both items and quests with the same code.
This is a very complex problem that I'm not qualified to answer, but I've seen lots of references to. The fundamental problem is that for games, quests and items and "stats" for various objects can have non-relational dependencies. This thread may help you a lot.
You might want to pick up a couple books on the topic, and look into using LUA as a rules processor.
Personally I would do this in code, not in SQL. Each item should be its own class implementing an interface (i.e. IItem). IItem would have a method called OkToPurchase that would determine if it is OK to purchase that item. To do that, it would use one or more of a collection of rules (i.e. HasPreviouslyPurchased(x), CurrentlyOwns(x), etc.) that you can build.
The nice thing is that it is easy to extend this approach with new rules without breaking all the existing logic.
Here's some pseudocode:
bool OkToPurchase()
{
if( HasPreviouslyPurchased('x') && !CurrentlyOwns('y') )
return true;
else
return false;
}
bool HasPreviouslyPurchased( item )
{
return purchases.contains( item )
}
bool CurrentlyOwns( item )
{
return user.Items.contains( item )
}

Resources