Dear Michael, Please guide me (or please show me direction) to solve this problem using Arangodb (if possible using ArangoDb)?
I have 2 documents A and B and Edge E *A,B : VertexE : Edge* what I want is every time A(some user) does perform some event and goes to vertex B I don't want to create new Relations if relation already exist between them. i.e if relationship already exist between A and B for some event, then I simply want to increase the counter of Edge E, without creating new Edges. how can I achieve This? Any help is highly appreciated..! Thanks..! On Mon, Sep 5, 2016 at 4:15 PM, Jan <[email protected]> wrote: > Hi, > > since 3.0 it is possible to create a unique index on the `_from` and `_to` > attributes. > This will make each combination of `_from` and `_to` in the edge > collection unique. > > db._createEdgeCollection("relations"); > db.relations.ensureIndex({ type: "hash", fields: ["_from", "_to"], > unique: true }); > > Inserting edges works as usual: > > db.relations.insert({ _from: "test/1", _to: "test/2" }); > { > "_id" : "relations/321436929", > "_key" : "321436929", > "_rev" : "321436929" > } > > db.relations.insert({ _from: "test/2", _to: "test/2" }); > { > "_id" : "relations/321436964", > "_key" : "321436964", > "_rev" : "321436964" > } > > But inserting an edge with the same `_from` and `_to` attribute values as > an already existing edge will now fail: > > db.relations.insert({ _from: "test/1", _to: "test/2" }); > JavaScript exception: ArangoError 1210: unique constraint violated > !db.relations.insert({ _from: "test/1", _to: "test/2" }); > ! ^ > stacktrace: ArangoError: unique constraint violated > at Error (native) > at <shell command>:1:6 > > Best regards > Jan > > Am Montag, 5. September 2016 12:24:06 UTC+2 schrieb prakash Pandey: >> >> Hi Michael, >> >> I am facing the same problem. You was talking about the feature to add. >> >> I am currently using 3.x.x. >> >> Is the feature available in this version?? >> >> On Monday, 27 October 2014 18:13:59 UTC+5:30, Michael Hackstein wrote: >>> >>> Hi Jérémy, >>> >>> i will add that as a feature request. >>> I think you are right and it is needed quite often. >>> I will keep you updated here. >>> >>> About the 3rd way, i think it is a good approach but there are some >>> things to consider: >>> * You can only use _key of your persons as "/" is not allowed within the >>> key. >>> * You have to add a spaceing symbol between both _key's which is not in >>> your _key values (if you do not set key's yourself in the vertices you can >>> go with "-" f.e.) >>> * If you are using several vertex collections the _key is probably not >>> unique. {_id: "v/1", _key:"1"}, {_id:"v2/1", _key:"1"} can coexist in >>> different collections, but key is equal. >>> >>> So in the list is nothing hard to implement in your logic, it is just to >>> avoid going into the trap ;) >>> >>> best >>> Michael >>> >>> >>> Am 27.10.2014 um 12:30 schrieb Jérémy Berthet <[email protected]>: >>> >>> Hello Michael, >>> >>> Thank you for your complete answer and suggestions. I've also thought >>> about a 3rd way, similar to the 2nd where I would use deterministic keys >>> for the edge (like the concatenation of person1_id and person2_id) to maybe >>> simplify the needed AQL a bit. >>> >>> Anyway, I was hoping that the graph module of Arango would offer a >>> standard function to find the edges existing between 2 vertices. Look like >>> it isn't the case. >>> >>> Regards, >>> Jérémy >>> >>> Le mercredi 22 octobre 2014 11:29:02 UTC+2, Michael Hackstein a écrit : >>>> >>>> Hi Jérémy, >>>> >>>> there are several conceptional approaches you could follow for your use >>>> case. >>>> I will try to explain all of them and give some hints on their pros & >>>> cons: >>>> >>>> 1) Create one edge per contact: >>>> * Simply store a new edge (_from, _to, details) for edge contact. >>>> + Will be fastest write performance. >>>> + You do not have to take care of writing conflicts if several >>>> instances are storing these edges. >>>> + You can directly see how many calls a person has made in total (to >>>> any other person) (Length of connected edges) >>>> - Edge collection grows rather fast >>>> - You have to write an AQL Filter to find all contacts between person A >>>> and B. >>>> >>>> 2) Create one edge per person-pair: >>>> * Store one (directed) edge per person pair and add a counter and all >>>> other relevant values. >>>> + Stored amount of data is minimal >>>> + You can directly see how many other persons one person has contacted >>>> (Length of connected edges) >>>> + You can directly see how many contacts a person has to a specific >>>> other person on one edge. >>>> + Graph-queries should perform faster as their runtime is typically >>>> bound by the amount of edges per vertex. >>>> - Requires a transaction for each write >>>> - Reduces write performance in case of many concurrent writers. >>>> >>>> >>>> I would always prefer version 2) above version 1) except one specific >>>> case, you have a large amount of concurrent writers of edges. >>>> >>>> To update the edge you can for example use the AQL statement: >>>> >>>> FOR contact in in_contact >>>> FILTER contact._from == @from AND contact._to @to >>>> LET oldCount = contact.count >>>> LET dates = contact.dates >>>> UPDATE contact WITH {count: oldCount + 1, dates: UNION(dates, >>>> [@newDate]) } in in_contact >>>> >>>> and replace the bindVars @from, @to, @newDate accordingly. >>>> This will then be transactional and can be used concurrently. >>>> >>>> hope that helps >>>> >>>> best >>>> Michael >>>> >>>> >>>> Am 21.10.2014 um 17:49 schrieb Jérémy Berthet <[email protected]>: >>>> >>>> Hello, >>>> >>>> I'm trying to play a bit with the concept of graph database. I have a >>>> simple use case to implement. This is not a real project, just something >>>> for testing how everything goes one. I'm tracing contact (let says phone >>>> call) between people and I want to log the date of each contact. I was >>>> thinking of a vertices collection called "person" and a unoriented relation >>>> definition "in_contact" beetween 2 persons. >>>> >>>> It is pretty easy to create an edge beetween 2 persons with the date >>>> for the first contact. But what to do when a second contact beetween the 2 >>>> same persons is happening ? I wanted to update the already existing edge >>>> data for adding the new date, but I couldn't figure out a simple way to >>>> find the id of an already existing edge given 2 persons id. >>>> >>>> Did I miss something ? Maybe my way to think is wrong and I should >>>> create a new edge on each contact with the date ? >>>> >>>> The final goal, in that use case, would be then to weight and report >>>> relations between people by the number and frequency of contacts. >>>> >>>> Thanks for any answer, >>>> Jérémy >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ArangoDB" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> ----------------------------------- >>>> >>>> Michael Hackstein >>>> >>>> >>>> eMail: [email protected] >>>> Mobil: +49-176-44410782 >>>> Fax: +49-221-2722999-88 >>>> >>>> >>>> triagens GmbH >>>> Hohenstaufenring 43-45 >>>> 50674 Köln >>>> >>>> >>>> Sitz der Gesellschaft: Köln >>>> Registergericht Köln; HRB 53597 >>>> >>>> >>>> Geschäftsführung: >>>> Dr. Frank Celler >>>> Martin Schönert >>>> Claudius Weinberger >>>> >>>> >>>> >>>> >>>> Diese e-Mail enthält vertrauliche und/oder rechtlich geschützte >>>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese e-Mail >>>> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und >>>> vernichten Sie diese e-Mail. Wir haben alle verkehrsüblichen Maßnahmen >>>> unternommen, um das Risiko der Verbreitung virenbefallener Software oder >>>> e-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen >>>> Virenkontrollen auf alle Anhänge an dieser e-Mail durchzuführen. Wir >>>> schließen außer für den Fall von Vorsatz oder grober Fahrlässigkeit die >>>> Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software >>>> oder e-Mails aus. >>>> >>>> >>>> This e-mail may contain confidential and/or privileged information. If >>>> you are not the intended recipient (or have received this e-mail in error) >>>> please notify the sender immediately and destroy this e-mail. We have taken >>>> precautions to minimize the risk of transmitting software viruses but >>>> nevertheless advise you to carry out your own virus checks on any >>>> attachment of this message. We accept no liability for loss or damage >>>> caused by software. >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ArangoDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "ArangoDB" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/arangodb/UDJF0Wv50Rw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ArangoDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
