Domain Model + Fetch Plans

Thread is closed for posting
14 posts, 0 answers
  1. Steve
    Steve avatar
    1886 posts
    Member since:
    Dec 2008

    Posted 10 Jun 2011 Link to this post

    Where can I get some info on Domain Model Fetch plans?
  2. Pencho
    Admin
    Pencho avatar
    22 posts

    Posted 13 Jun 2011 Link to this post

    Hi Steve,

    You could take a look at the following topics:

    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
    Q1’11 SP1 of Telerik OpenAccess is available for download; also available is the Q2'11 Roadmap for Telerik OpenAccess ORM.
  3. Steve
    Steve avatar
    1886 posts
    Member since:
    Dec 2008

    Posted 13 Jun 2011 Link to this post

    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
  4. Steve
    Steve avatar
    1886 posts
    Member since:
    Dec 2008

    Posted 13 Jun 2011 Link to this post

    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?
  5. Dimitar Kapitanov
    Admin
    Dimitar Kapitanov avatar
    632 posts

    Posted 17 Jun 2011 Link to this post

    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
    Q1’11 SP1 of Telerik OpenAccess is available for download; also available is the Q2'11 Roadmap for Telerik OpenAccess ORM.
  6. IT-Als
    IT-Als avatar
    381 posts
    Member since:
    Sep 2008

    Posted 17 Jun 2011 Link to this post

    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






  7. Steve
    Steve avatar
    1886 posts
    Member since:
    Dec 2008

    Posted 17 Jun 2011 Link to this post

    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
  8. Dimitar Kapitanov
    Admin
    Dimitar Kapitanov avatar
    632 posts

    Posted 20 Jun 2011 Link to this post

    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
    Q1’11 SP1 of Telerik OpenAccess is available for download; also available is the Q2'11 Roadmap for Telerik OpenAccess ORM.
  9. IT-Als
    IT-Als avatar
    381 posts
    Member since:
    Sep 2008

    Posted 20 Jun 2011 Link to this post

    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
  10. Dimitar Kapitanov
    Admin
    Dimitar Kapitanov avatar
    632 posts

    Posted 20 Jun 2011 Link to this post

    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
    Q1’11 SP1 of Telerik OpenAccess is available for download; also available is the Q2'11 Roadmap for Telerik OpenAccess ORM.
  11. Steve
    Steve avatar
    1886 posts
    Member since:
    Dec 2008

    Posted 20 Jun 2011 Link to this post

    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 :)
  12. IT-Als
    IT-Als avatar
    381 posts
    Member since:
    Sep 2008

    Posted 21 Jun 2011 Link to this post

    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
  13. Dimitar Kapitanov
    Admin
    Dimitar Kapitanov avatar
    632 posts

    Posted 24 Jun 2011 Link to this post

    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
    Q1’11 SP1 of Telerik OpenAccess is available for download; also available is the Q2'11 Roadmap for Telerik OpenAccess ORM.
  14. IT-Als
    IT-Als avatar
    381 posts
    Member since:
    Sep 2008

    Posted 24 Jun 2011 Link to this post

    Hi Ditimar,

    Thanks for sharing the info.

    Regards

    Henrik
Back to Top