Ok, I was thinking that fetchplan is atomic but of course it's not.  I 
won't worry about speed then and I'll be more careful of consistency.  
Thanks.


On Wednesday, April 2, 2014 11:02:06 AM UTC-4, Andrey Lomakin wrote:
>
> HI, 
> Actually you are right.
> Some of vertexes will be different, but that is not resolved by fetchplan 
> , once you commit data inside of the middle  data fetch it always be some 
> data which are out of dated.
> But I see requests from other users to support fetchplan on embedded 
> storage, so possibly we implement it.
>
> About speed, speed will be the same I give you my word :-).
>
>
> On Mon, Mar 31, 2014 at 11:07 PM, odbuser <[email protected] <javascript:>
> > wrote:
>
>> Oh, I didn't realize that fetch plan is only for remote: and http: access.
>>
>> I don't see this in the wiki:
>> https://github.com/orientechnologies/orientdb/wiki/Fetching-Strategies
>>
>> Wouldn't this be important for consistency and speed?
>>
>> For consistency, fetching based on a plan in one shot guarantees that 
>> everything is consistent as of that point in time.  Otherwise, if the graph 
>> is walked over say 30 seconds in an actively updated graph, lots of Vs and 
>> Es are going to be inconsistent with the first select or am I missing 
>> something?
>>
>> For Speed, I would think that getting everything in shot will improve 
>> performance b/c 1 read could be done instead of 100s.  Even though it's 
>> plocal access, there's still a lot of overhead (I don't have proof of this 
>> but am assuming there is a substantial amount with larger result sets).
>>
>>
>> On Monday, March 31, 2014 11:49:02 AM UTC-4, Andrey Lomakin wrote:
>>
>>> HI,
>>> Fetch plan is used in remote and http protocols.
>>> Why do you need it in embedded database ?
>>>
>>>
>>>
>>> On Thu, Mar 27, 2014 at 8:53 PM, cp2 <[email protected]> wrote:
>>>
>>>> using 1.7rc2 SNAPSHOT from 10 March,  2014 
>>>>
>>>> Either I am doing it wrong or FetchPlans seem to be ignored running 
>>>> embedded and plocal.
>>>> If I disable all caching, I get only the local record,
>>>> I use default caching, I get back the entire connected object tree
>>>>
>>>> Tested using the schema and data  from the Fetch Plan wiki page 
>>>> https://github.com/orientechnologies/orientdb/wiki/Fetching-Strategies
>>>>
>>>> with caching disabled, I always get this for fetch plans: *:-2 *:0 *:1 
>>>> *:-1 
>>>> and no fetch plan
>>>> *Invoice#11:0{out_customers:#12:0,out_addresses:#13:0,out_orders:[size=3]} 
>>>> v7*
>>>>
>>>> with default caching I get for all  records regardless of fetch plan:
>>>>
>>>> * 
>>>> Invoice#11:0{out_customers:#12:0,out_addresses:#13:0,out_orders:[LineItem#16:0{count:5,in_orders:#11:0,out_order_item:#17:0}
>>>>  
>>>> v4, LineItem#16:1{count:3,in_orders:#11:0,out_order_item:#17:1} v4, 
>>>> LineItem#16:2{count:4,in_orders:#11:0,out_order_item:#17:2} v4]} v7*
>>>>
>>>> Also, using the debugger, with caching enabled, I can browse the entire 
>>>> object graph from the Invoice document -- which I would expect only for 
>>>> fetch plan *:-1.  
>>>> When I have caching disabled, all I can see are the RIDs of linked 
>>>> documents, which I would only expect for fetch plan *:0 or *:-2
>>>>
>>>> this is my code
>>>>
>>>> 'select from Invoice'
>>>>
>>>>
>>>>
>>>>
>>>> *static List<ODocument> query(OrientGraph pGraph, final String pSql, 
>>>> final String pFetchPlan) {  final OQueryAbstract zQuery = new 
>>>> OSQLSynchQuery(pSql).setFetchPlan(pFetchPlan);   return 
>>>> pGraph.getRawGraph().query(zQuery);}*
>>>>  
>>>> This leaves me confuse about what the fetch plan does. I don't want my 
>>>> queries returning the whole graph. What am I doing wrong?
>>>>  
>>>> -- 
>>>>
>>>> --- 
>>>> 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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Best regards,
>>> Andrey Lomakin.
>>>
>>> Orient Technologies
>>> the Company behind OrientDB
>>>
>>>   -- 
>>
>> --- 
>> 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.
>>
>
>
>
> -- 
> Best regards,
> Andrey Lomakin.
>
> Orient Technologies
> the Company behind OrientDB
>
>  

-- 

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