-
Notifications
You must be signed in to change notification settings - Fork 871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow UPSERT of Edges #4436
Comments
👍 would also like to see this |
several changes here: - addImageBlob and addPerson now return the `Vertex` for the added blob and the added `Canonical`, wrapped in a case class called `AddBlobResult` (could use a rename). This is needed because just returning the `Canonical` would require querying for the canonical's `Vertex` if we want to reference it, and that query will fail if the transaction is uncommitted. - uses of `Vertex.lift` are wrapped in try/catch blocks to catch the `OStorageException` that will be thrown if the vertex does not already exist. - The `addPerson` and `addImageBlob` both call through to a generic `addMetadataBlob` function, which will query for existing blob and canonical, or add blob & create canonical if none exists
+1 |
3 similar comments
+1 |
+1 |
+1 |
This, if implemented, would support queries like this (multiple edges creation):
Am I right? |
+1 |
hey, |
I guess in meantime the good ol' if statement have to suffice |
+1 |
+1 |
+1, this would be great |
+1 |
+1 |
5 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
Going on three years now. I personally dealt with this by using something instead of OrientDb. |
+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. |
I mean this is open source, everybody can make a pull request, you know 😁 |
Hi guys, Let me give some context here. 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 There are a few problems in this approach though:
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 |
I have a simple and quick solution to this: without breaking anything, what if we create the WDYT? |
Well... why not? We can definitely go with this approach Thanks Luigi |
Thank you both for the additional details on this topic. |
That approach sounds perfect - thank you! |
+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. |
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 |
Little note: as discussed above, for new the UPSERT only works in the case you have a UNIQUE index on Thanks Luigi |
Hi I am trying to implement this new upsert edge feature available with v3.0.3 but getting exception |
@luigidellaquila could it be documented anywhere how to create a unique index on |
Currently, UPSERT can only handle vertices. For my purposes, I would like/need to be able to upsert edges as well.
The text was updated successfully, but these errors were encountered: