Thank you for the idea. That's the direction I was going. It does work, of 
course, I was just hoping for a more elegant solution.

PS (to OrientDB): It would be so nice if the Javascript engine used for 
functions supported ES6 template strings 
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals).


On Wednesday, June 1, 2016 at 11:44:36 AM UTC-5, Ivan Mainetti wrote:
>
> Hello,
>
> I think that the only way to do what you need is by using a function:
>
> I wrote this javascript:
>
> parameters: rid, map_name, key_name, key_value
>
> var g=orient.getGraph();
>
> var sel=g.command("sql","select expand("+map_name+"."+key_name+") from "+
> rid+" where '"+key_name+"' in "+map_name+".keys()");
>
> if(sel.length > 0){
>   return sel[0]
> } else {
>   var upd=g.command("sql","update "+rid+" put "+map_name+"='"+key_name+
> "',"+key_value+" return after @this."+map_name+"['"+key_name+"']");
>   return upd[0];
> }
>
> then here's an example of usage:
>
> select 
> expand(function_name('#23:0','lista','key7',"{'Action':'Test22a','Enabled':false,
>  
> '@type':'d', '@class':'Test'}"))
>
>
>
>
> Il giorno mercoledì 1 giugno 2016 06:38:14 UTC+2, Eric24 ha scritto:
>>
>> I'm trying to determine the most efficient and least contentious way to 
>> do a sort of UPSERT on a LINKMAP property. Specifically, if I try to PUT a 
>> new item with a key value that already exists, I want the PUT to fail and 
>> leave the existing item in place (and instead return that item to the 
>> caller). By default, a PUT overwrites the key-matching item. I can prevent 
>> that with a WHERE clause, but I can't get RETURN to work (no syntax I've 
>> tried works). I can accomplish this doing a SELECT first, followed by a 
>> conditional UPDATE, but I'm hoping there's a more efficient way.
>>
>> Also, this is a very high-frequency operation (many potential update or 
>> update attempts to a given record per second). What happens to a single 
>> record with a LINKMAP (or EMBEDDEDMAP) property if one operation adds a new 
>> key/record and a concurrent operation adds a new different key/record? Are 
>> both keys/records retained or does the most recent update "win", 
>> effectively loosing the key/record added in the first operation or are both 
>> retained? If so, would locking the record during the operation solve that 
>> issue?
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"OrientDB" 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.

Reply via email to