Edge's in and out properties not set properly.

Expected behavior and actual behavior

I am trying to create an edge KNOWS between Person and CustomUser vertexes. CustomUser vertex has Person as its superclass. I am trying to do this using a batch script as follows.

orientdb {db=konnect}> begin
orientdb {db=konnect}> let person = select from person where uid = 100
orientdb {db=konnect}> let su = select from customuser where uid = 9199853
orientdb {db=konnect}> let knows = update knows set in = $su.@rid, out=$person.@rid content {"name": "Yolo"} upsert return after @this where in=$su.@rid and out=$person.@rid
orientdb {db=konnect}> return $knows
orientdb {db=konnect}> commit

It seems like the knows edge is created but the in and out properties are not being set to $person’s and $su’s rids properly. Following is the result I see.

----+----------+------+----+----+----------+------------+------------+------+----
#   |@RID      |@CLASS|in  |out |_allowRead|_allowUpdate|_allowDelete|_allow|name
----+----------+------+----+----+----------+------------+------------+------+----
0   |#23:122788|KNOWS |[1] |[1] |null      |null        |null        |null  |Yolo
----+----------+------+----+----+----------+------------+------------+------+----

Steps to reproduce the problem

orientdb {db=konnect}> begin
orientdb {db=konnect}> let person = select from person where uid = 100
orientdb {db=konnect}> let su = select from customuser where uid = 9199853
orientdb {db=konnect}> let knows = update knows set in = $su.@rid, out=$person.@rid content {"name": "Yolo"} upsert return after @this where in=$su.@rid and out=$person.@rid
orientdb {db=konnect}> return $knows
orientdb {db=konnect}> commit

Important Questions

Why does the result show in and out property values as [1]. What does [1] denote here ?

Runninng Mode

• Embedded, using PLOCAL access mode
• Embedded, using MEMORY access mode
• Remote

Misc

• I have a distributed setup with multiple servers. How many?
• I’m using the Enterprise Edition

OrientDB Version

• v2.0.x - Please specify last number:
• v2.1.x - Please specify last number:
• v2.2.x - Please specify last number:

Operating System

• Linux
• MacOSX
• Windows
• Other Unix
• Other, name?

Java Version

• 6
• 7
• 8

[smolinari]

Pardon me if it sounds stupid but I don’t know what the fundamental differences are between neo4j and orientdb.

Oh no! Please don’t get me wrong. I might be the stupid one. 😄

However, I know in ODB, you can add a subdocument containing multiple email addresses, if you want.

So do you suggest making separate queries for the above ?

Since you meant transaction, that does change the context. However, yes. I’d still keep the work being done separate, since we are talking about mutations and not just querying. So, this might be two different functions. If you do have the emails as subdocuments, you could do an upsert (update with upsert) for that mutation and then add the friend edge as another mutation function.

Please correct me, if I am wrong but I was under an impression that merging queries and using transactions helps reduce the number of writes on the db and improves the network latency.

That is what I understand too. 😄 None-the-less, the more important feature of a transaction is to make sure the tasks being done in the database are done as an atomic process, as in ACID like. 😄

Now, that all being said, there shouldn’t be any reason why you can’t combine the two mutations with logic, to come up with the final transaction. But, is it really important to update or insert a user an email address and also add a friend relationship atomically? I don’t think so. You must also remember, once you start a transaction, those records are locked for everyone else, until the commit is finished.

The other possibility you should look at for combining queries is the batch processing. OrientDB allows you to batch together commands and have them be carried out optimistically. It is similar to the transaction you have. http://orientdb.com/docs/2.2/SQL-batch.html

Scott

[amyth]

I can’t believe this requirement could be done in a single query in any database. My bad, I meant in a single transaction. For example you can do this in NEO4J as follows:

merge (user:User {uid: "x"})
merge (email:Email {email: "[e-mail]"})
merge (email)<-[:HAS]-(firend:User)
merge (friend)-[:FRIENDS_WITH]->(user)

why one would have an extra vertex for email addresses ?

Guess to support multiple email addresses ? Pardon me if it sounds stupid but I don’t know what the fundamental differences are between neo4j and orientdb. Currently the schema we use is based on what we had decided for neo4j and have simply imported the data to orientdb. How can we support multiple email addresses for a single user vertex in orientdb without using email as a vertex ?

From a reusability and responsibility perspective, I’d want them separate anyway.

So do you suggest making separate queries for the above ? And if that’s the case would it simply not increase the number of queries we are making to the db ? If I have a list of 1000 friends that I want to update and if on an average I am making 4 queries to update a single friend, it’d be 4000 queries. And each query that i’d make won’t I be adding up on network latency with each query ?

Please correct me, if I am wrong but I was under an impression that merging queries and using transactions helps reduce the number of writes on the db and improves the network latency.