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].
For more options, visit https://groups.google.com/d/optout.

Reply via email to