Orientdb: Allow UPSERT of Edges

[Bandes]

Currently, UPSERT can only handle vertices. For my purposes, I would like/need to be able to upsert edges as well.

[bomgar]

:+1: would also like to see this

[justinkillen]

+1

[amyth]

+1

[kubz]

+1

[strohni]

+1

[suyogdilipkale]

I am able to upsert for edge class with following syntax:

UPDATE LikeComment SET out = #21:21, in = #20:20 UPSERT WHERE out = #21:21 and in = #20:20

But When I select source vertex like SELECT FROM #21:21 it does not show me that out edge in result.

[karolmie1]

This, if implemented, would support queries like this (multiple edges creation):

UPDATE EDGE hasAssignee FROM ( SELECT FROM Project WHERE id=:id ) TO ( SELECT FROM User WHERE login in :login ) UPSERT

Am I right?

[oger-p]

+1

[zeeshan2709]

hey,
I am using
update has SET out=#20:16, in=#14:18 UPSERT WHERE out = #14:18 and in = #20:16
It does not create the edge if not present. Is this feature not yet implemented. If not, can you suggest any workaround for this.
usecase is to create edge only if it does not exist.

[karolmie1]

I guess in meantime the good ol' if statement have to suffice

[grindhold]

+1

[lightjiao]

+1

[undecided2013]

+1, this would be great

[micha-nerdlichter]

+1

[thenerdnest]

+1

[timobanion]

+1

[gauravssFlipkart]

+1

[triketora]

+1

[WalterInSH]

+1

[feiYH]

+1

[grzegorz-aniol]

+1
I'm really surprised this feature is not available yet in orientdb. How people deal with this problem during cyclic update/import data??

[bernierm]

Going on three years now. I personally dealt with this by using something instead of OrientDb.

[david-sitsky]

+1. This is a really important feature for us if OrientDB is to be used in a real-world / real-time mass graph database application.

Can't you give us users any indication if this is being considered? Otherwise we'll keep moving to other options.

[karolmie1]

I mean this is open source, everybody can make a pull request, you know :grin:

[luigidellaquila]

Hi guys,

Let me give some context here.
We consider this as an important feature, we really would like to have an easy and performant way to implement it, but unfortunately we still don't have one.

A consistent UPSERT is based on the assumption that you have a way to detect duplicates. Now, we have unique indexes for this in OrientDB, so we could define a unique index on E(out, in).

There are a few problems in this approach though:

1. an index requires a schema, right now E class does not have a schema for the properties out and in. There is a good reason for this: in some cases you need your edges to define out and in as links to a specific type (eg. you want FriendOf.out to be LINK Person, just to avoid creation of friendship relationships that point to something other than people). Many of our customers and OSS users already rely on edge schema, so we cannot break it
2. as long as you have a uniqueness violation mechanism in place, using it in TX is easy, but implementing it in NoTx is a bit more complex and requires some time and patience.
3. having an additional index on edges by default will result in a slowdown at insertion time, that is not reasonable in general, especially for use cases where you don't need UPSERT at all

Of course this is an open discussion, so if you have any ideas or suggestions on how to implement it in a different ways, we are open to take it into consideration (and we would appreciate it a lot)

Thanks

Luigi

[lvca]

I have a simple and quick solution to this: without breaking anything, what if we create the UPSERT EDGE command, but it throws an exception if there is no unique index? In this way, users that want the UPSERT EDGE must create an index first. We can put this in documentation and in the exception.

WDYT?

[luigidellaquila]

Well... why not? We can definitely go with this approach

Thanks

Luigi

[bjornarl]

Thank you both for the additional details on this topic.
I believe Luca's suggestion would work for us -- I was going to ask about that possibility, as we already have an added edge column that has a unique index. It would be great if it could work in a NoTx scenario, though I understand from Luigi's point 2 that that might be more involved to handle.

[david-sitsky]

That approach sounds perfect - thank you!

[v1nsai]

+1 This would really improve the system as I think preventing creation of duplicates is one of the more basic functions we're all going to deal with. We can use multiple queries but this quickly creates lots of extra overhead.

[luigidellaquila]

Hi all,

I just implemented this feature and pushed the enhancement to develop branch. This will be released with v 3.0.1.

I think this is the most voted enhancement in the history of OrientDB, thank you all for helping to find the best solution for this.

Thanks

Luigi

[luigidellaquila]

Little note: as discussed above, for new the UPSERT only works in the case you have a UNIQUE index on EdgeClass[out,in]

Thanks

Luigi

[gtadudeps]

Hi I am trying to implement this new upsert edge feature available with v3.0.3 but getting exception com.orientechnologies.orient.core.exception.OCommandExecutionException: Error updating edge: 'out' is not a vertex. I have created a class Person with Name field as unique index and Friend with field id as unique index. Command issued : update edge Friend set in = (select from Person where Name = 'name1' ) , out = ( select from Person where Name = 'name2') , id = 'f1' upsert where id = 'f1'. Please let me know if I am using this correctly. Thanks!

[mebibou]

@luigidellaquila could it be documented anywhere how to create a unique index on EdgeClass[out,in] for the UPSERT to work? I've been at this for days and still can't find a way to do this