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 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.
