Include implementation for LINQ queries

Apr 19, 2011 at 6:08 PM

Hello

My name is Sergio Navarro, and I'm evaluating Sterling DB

In order to take a decision I would like to know whether is it a big problem to have available a new characteristic on Sterling DB
I would need an include() method, similar to the one provided by EF in the object ObjectQuery, which can by applied to the results of a LINQ query.

It would be very useful to have this method just because depending of the context of your query you have different needs of data. Some times you need some object children of the object included on the resulting object/s of the query and other times you need other children objects. It would be useful that the include method allow the developer to decide which object children should be eager loaded for each query in the same way EF does.

Currently the only option I have found is to navigate through indexes without loading an object. However as soon as we access an object all its hierarchy is loaded. This is not very efficient if I only need to read a primitive property of the object or if  I only need certain child object, is it?.

Is there any alternative to perform LINQ  queries using a kind of include method?

Regards

Coordinator
Apr 19, 2011 at 6:18 PM

Yes, we are considering this. Most likely what will happen is you will pass a predicate to the load method. The predicate will be called for each child type and you will specify whether or not you want it loaded.

So for something like this:

public class Contact 
{
   public int Id { get; set; }
   public string Name { get; set; }
   public IList<Address> Addresses { get; set; }
}

You would suppress loading addresses like this:

var contact = _database.Load<Contact>(contactId, type => !type.Equals(typeof(Address));

You can overload as many children as you like and the default will be to load everything.

I don't have an estimate of when that will go in yet, but it may be an easier implementation that makes it to the 1.5 release.

 

Apr 19, 2011 at 6:48 PM
Edited Apr 19, 2011 at 6:53 PM

Great, It seems even better, however, for compatibility reasons I will be happy if it is configurable a mode where by default nothing is loaded. I'm migrating a subset of a desktop app based on EF to WP7 and I would like to reuse 99% of the code because the two aplicattions will continue growing together for a long time (I hope so) :)

A question regarding the use of the new predicate for the Load method in this scenario:

public class Order 
{
   public int Id { get; set; }
   public IList
OrderDetail { get; set; } }
public class OrderDetail 
{
   public Order ParentOrder { get; set; }
   public int LineNumber { get; set; }
   public Product { get; set; }   
   public int Quantity { get; set; }
    
}

public class Product

{
   public int Id { get; set; }
   public string description { get; set; }   
   public double description { get; set; }    
}

If you want to perform a query to retrieve orders with its order details but without its products how would you do it? In this way?

var contact = _database.Load<Order>(orderId, type => !type.Equals(typeof(Product));

Thank you for your quick and clear answer.
Regards!

El 19/04/2011 19:18, jeremylikness escribió:

From: jeremylikness

Yes, we are considering this. Most likely what will happen is you will pass a predicate to the load method. The predicate will be called for each child type and you will specify whether or not you want it loaded.

So for something like this:

public class Contact 
{
   public int Id { get; set; }
   public string Name { get; set; }
   public IList
Addresses { get; set; } }

You would suppress loading addresses like this:

var contact = _database.Load<Contact>(contactId, type => !type.Equals(typeof(Address));

You can overload as many children as you like and the default will be to load everything.

I don't have an estimate of when that will go in yet, but it may be an easier implementation that makes it to the 1.5 release.

 

 

Coordinator
Apr 19, 2011 at 7:22 PM

Honestly while I appreciate the situation you are in and the desire for compatibility, I am not trying to build parity with EF ... that will grow and it already has it's place via RIA services which I anticipate will grow with support on the phone. I've looked at a lot of different models for lazy loading and most seem to be based on either the type or the property name so I'm still considering the best way. Any implementation will need to be backwards compatible, however, and because right now the default is to load the whole hierarchy, that will need to be the default in future versions as well.

You are correct regarding the example you provided. I may actually make the predicate take a type and a property name for more granularity.

Thanks,

Jeremy

Apr 19, 2011 at 7:35 PM
I understand.

I will keep an eye on next releases then.

Regards


El 19/04/2011 20:22, jeremylikness escribió:

From: jeremylikness

Honestly while I appreciate the situation you are in and the desire for compatibility, I am not trying to build parity with EF ... that will grow and it already has it's place via RIA services which I anticipate will grow with support on the phone. I've looked at a lot of different models for lazy loading and most seem to be based on either the type or the property name so I'm still considering the best way. Any implementation will need to be backwards compatible, however, and because right now the default is to load the whole hierarchy, that will need to be the default in future versions as well.

You are correct regarding the example you provided. I may actually make the predicate take a type and a property name for more granularity.

Thanks,

Jeremy