oh, I didn't know this. I've only used remote so far. 

On Saturday, March 21, 2015 at 7:28:02 PM UTC, Adithyan K wrote:
>
> Your requirement will not work if you connect orientdb in remote mode. If 
> you do in plocal mode, your expectation will work perfectly. That is the 
> feature currently. This information is available also in 
> http://www.orientechnologies.com/docs/last/orientdb.wiki/Transactions.html#breaking-of-acid-properties-when-using-remote-protocol-and-commands-sql-gremlin-js-etc
>
> You can see the below issues for more information
>
> https://github.com/orientechnologies/orientdb/issues/3018 
> https://github.com/orientechnologies/orientdb/issues/3139
>
> On Sat, Mar 21, 2015 at 4:57 PM, syshex <[email protected] <javascript:>> 
> wrote:
>
>> Hi,
>>
>> If you cache an existing Vertex , and for whatever reason it changes ( 
>> because other bit of code in another place changes the object in the db ) , 
>> then when you perform changes to the cached Vertex and try to persist it, 
>> the transaction will fail with exception , because the Version of the 
>> object will be wrong.
>>
>> Hope this helps.
>> Rui
>>
>> On Saturday, March 21, 2015 at 7:55:38 AM UTC, Sathwik B P wrote:
>>>
>>> Hi,
>>>
>>> Thanks for your clarification.
>>>
>>> I believe there is no other way than cashing the new added data.
>>>
>>> I am not sure what happens in case of update to existing data. Will the 
>>> re-read get the old committed data itself.
>>> If the case be then it turns out that one has to cache both committed 
>>> and uncommitted data till the transaction commits.
>>>
>>> regards,
>>> sathwik
>>>
>>> On Friday, 20 March 2015 21:28:02 UTC+5:30, syshex wrote:
>>>>
>>>> Hi ,
>>>>
>>>> I'll give you my understanding from my experience so far with OrientDB. 
>>>> It is based on my observations and the conclusions might be wrong, but 
>>>> still:
>>>>
>>>> - When you use a TX connection, the vertex and edges only exist after 
>>>> the commit . If you do a  graph.addVertex()  inside a transaction, it 
>>>> returns a Vertex object, and if you look at the RID of the object you'll 
>>>> see it is using negative numbers, which I think are "placer" rids used to 
>>>> map edges and other vertices connections.  So, the RID of the Vertex is 
>>>> not 
>>>> a "valid" one.  Once you commit, those objects are persisted and given 
>>>> proper RIDs. 
>>>>  
>>>> That said, I haven't tried to perform a search for a Vertex inside a 
>>>> running  transaction , in which I created that vertex.
>>>>
>>>> Hope this helps.
>>>> Rui
>>>>
>>>> On Friday, March 20, 2015 at 1:28:19 PM UTC, Sathwik B P wrote:
>>>>>
>>>>> Hi syshex,
>>>>>
>>>>> Adding vertices and edges are 2 independent API calls.
>>>>>
>>>>> It's an event window where vertices and edges information come in from 
>>>>> external sources, the vertices/edges can already be either committed data 
>>>>> or to be added newly. So caching all the vertices/edges objects and 
>>>>> passing 
>>>>> it along all the API methods which need access to them is not the 
>>>>> solution 
>>>>> I am looking for.
>>>>>
>>>>> regards,
>>>>> sathwik
>>>>>
>>>>> On Friday, 20 March 2015 18:16:24 UTC+5:30, syshex wrote:
>>>>>>
>>>>>> Hi, when you create both vertex1 and vertex2, why don't you keep a 
>>>>>> reference to those and use those references to add the edge?
>>>>>>
>>>>>>
>>>>>> On Friday, March 20, 2015 at 12:29:18 PM UTC, Sathwik B P wrote:
>>>>>>>
>>>>>>> Hi Guys,
>>>>>>>
>>>>>>> OrientDB 2.0.2
>>>>>>>
>>>>>>> Transaction is started, 2 vertices are added. In order to create an 
>>>>>>> edge between the 2 newly added vertices we query for the vertex again 
>>>>>>> from 
>>>>>>> the graph. It turns out to return a null object.
>>>>>>>
>>>>>>> *Are objects added in the same transaction not visible for re-reads?*
>>>>>>>
>>>>>>> Here is the scenario.
>>>>>>>
>>>>>>> Transaction begin
>>>>>>>
>>>>>>> Add vertex1
>>>>>>> Add vertex2
>>>>>>>
>>>>>>> Add edge
>>>>>>> *     Get vertex1 -> this is null object*
>>>>>>>
>>>>>>> Transaction commit
>>>>>>>
>>>>>>> regards,
>>>>>>> sathwik
>>>>>>>
>>>>>>  -- 
>>
>> --- 
>> 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] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

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