Domain Model + Fetch Plans

[sitefinitysteve]

Where can I get some info on Domain Model Fetch plans?

[Pencho]

Hi Steve,

You could take a look at the following topics:

• http://www.telerik.com/help/openaccess-orm/getting-started-root-getting-started-with-fetchplans.html
• http://blogs.telerik.com/openaccessteam/posts/10-07-21/new_fetch_optimization_api.aspx

We would also like to ask you, did you have problems finding the information for the Fetch API in the documentation, or you just turned to the support? This information is very important for us so that we know if we should improve the structure of our documentation.
If you have further questions, do not hesitate to contact us.

Best wishes,
Pencho
the Telerik team

[sitefinitysteve]

Thanks I'll try these...

I looked at the Docs, but they seemed to reference the older ObjectScope method (this is the first search result)

It's sometimes just hard to find stuff in the docs because the results are inter-mingled with API Reference articles

[sitefinitysteve]

Ok so question on this...

I use OA in a web context, and we use a shared context for the entire page lifecycle

So if I set this

FetchStrategy fetchStrategy = new FetchStrategy();
fetchStrategy.LoadWith<Customer>(c => c.Orders);
fetchStrategy.LoadWith<Order>(c => c.OrderDetails);
dbContext.FetchStrategy = fetchStrategy;

...does that then screw this context so it'll load those objects everywhere?

Is there no way to define the Fetch in the model such that object X always loads with a fetch plan?

[Dimitar Kapitanov]

Hi Steve,
First of all apologies for the late reply. Indeed our fetch optimizations are defied on the context level (the context is our UnitOfWork implementation and we consider that the place for the fetch optimization strategy is carefully selected). That way you are able to change the behavior of different contexts. Since we guarantee uniqueness of the objects in memory, if we've added the optimization definition on the object level, you will end up with a behavior that mimics a 'singleton' - you will define the behavior globally for this object, while in the other case you will be able to modify it accordingly based on the context instance and its pattern of usage. Can you elaborate a bit more on what are you trying to achieve, the exact behavior? That way we will be able to see if you hit a fault behavior or we lack some really important functionality that you need?
Thanks in advance.

Greetings,
Dimitar Kapitanov
the Telerik team

[IT-Als]

Hi Steve (and Dimitar),

Huh? I wasn't aware of this problem actually. However, a better place to define the fetch strategy / field would be on the query level somehow. It is "bound" to how the query should be optimized - not the UnitOfWork (what I sometimes call the "business transaction". Take the web application scenario as an example:

We follow the best practice of one thread - one context   (to make it simple, one thread is equivalent to one request going to the web server):

During this "business transaction" we might query the same entity twice or more with different fetch definitions...  Thus I think it is more "bound" to the query than the Context

Regards

Henrik

[sitefinitysteve]

We also use the one shared context across the entire webrequest

So if you use AspNetUsers as the root object\table, this has a TON of nav properties off of it as it's the users table.  I'd like to define a fetch off of it depending on the application I'm in...

Our shared context is available from a base class we have inheriting from Page.

...but I'm new to all this, I'm just looking to squeeze any performance I can out of my DB

[Dimitar Kapitanov]

Hello Henrik,
Being able to define fetch optimizations on the query level is definitely a must, and we will implement such an API that will act as fetch optimization only for the query instance it is defined (similar to the 'Include' functionality in EF queries). However we didn't released such an API in public for our new Context-based API. It is still to be finalized and after that released. In general you are still using the context, but since it lives shortly (one thread/one HTTP request) the overall behavior mimics I assume what I've just described? Is that correct or am I missing something?

Regards,
Dimitar Kapitanov
the Telerik team

[IT-Als]

Hi Dimitar,

Thanks for the response.

Yes, it would really be great with such an API. Basically it will need to go one level deeper than the Context scoped fetch optimizations. So that it is scoped by the Query instead of the Context. When the query is executed (server side) it is disposed.

Again, consider the scenario that during a request to a WCF service...  You will need a simple query to return a subset of countries only taking a few fields and a specific collection field. However, during the same request (in another query) you will need the full list of countries will all fields and all collection fields, too..

I don't think this is possible with the current Context scoped API, because you can not change a fetch definition when it is first added to the Context...if I remember correctly.  First added, it stays there until the Context is disposed, right?

Regards

Henrik

[Dimitar Kapitanov]

Hello Henrik,
Totally true, but then again the context should live usually 'per request', that is how you can achieve the API I've mentioned today - the recreation of the context should not be considered an 'expensive operation', basically it should be the same as IObjectScope with the 'classic' API. That means that with a call to a service that requires a different setup, why just not use a 'specialized' context with the appropriate Fetch strategy?  Did I understood the situation correctly?

All the best,
Dimitar Kapitanov
the Telerik team

[sitefinitysteve]

This is what I would like to see

Current:

NorthwindContext context = new NorthwindContext();

FetchStrategy fetchStrategy = new FetchStrategy();
fetchStrategy.LoadWith<Order>(o => o.Employee);
// or use the overload:
// fetchStrategy.LoadWith((Order o) => o.Employee);
context.FetchStrategy = fetchStrategy;

IQueryable<Order> orders = context.Orders;

Ideal (for me anyway)...keeps it flexable per query instead of having multiple contexts per object\scenario

IQueryable<Order> orders = context.Orders.LoadWith(fetchStrategy);

...but again, I'm new to this concept :)

[IT-Als]

Hi Steve and Ditimar,

@Ditimar:
It kinds of breaks with the one thread - one context approach if you have multiple specialized contexts for each request. And you're really loosing L1 cache because it is bound to the Context and as far as I'm concerned L1 caches cannot be shared among Context..

@Steve:
Yes, exactly something link that I had in mind...... you just put the code to it ;-)

Regards

Henrik

[Dimitar Kapitanov]

Hi Guys,
@ Steve:
That is the API under development that you will get (so I think we are thinking in the right direction).

@Henrik:
You are right, I just wanted to say that you can go that way if it has more benefits to it than the two limitations you've mentioned (L1 and threading). I think there are cases when this can be even a better solution.

Best wishes,
Dimitar Kapitanov
the Telerik team

[IT-Als]

Hi Ditimar,

Thanks for sharing the info.

Regards

Henrik