Retrieve Data from WCF - Object Graph Issues

Mar 12, 2011 at 1:11 PM
Edited Mar 12, 2011 at 1:56 PM

I am just new to Sterling database.  In my Windows Phone 7 application when the application starts, if no data exists in the database, I retrieve the intitial data from a WCF service - it is a separate call to the WCF service to retrieve a collection for each table.  I then save the retrieved data into the database.  After that I load the data into Observable Collections in my view model.  The problem that I have is that when I try to databind to my view model it does not have information on referenced classes (unless I download the entire object graph for each table (using include statements) from the WCF service).   I can see that all the foreign keys exist in the database, however the references are not populated.  I was trying to avoid having to download the entire object graph from the WCF service and hoping that because each table had the key it would then be enough to walk the object graph and populate the references when sterling loaded the objects.  Do I have to download the entire object graph from my WCF service or am I just using the wrong techniques to load my data?

Some code snippets follow:

//Downloading data
void OpenReadCompletedCategoryTypes(object sender, OpenReadCompletedEventArgs e)
            DataContractSerializer ser = null;

                ser = new DataContractSerializer(typeof(ObservableCollection<CategoryType>));
                var items = ser.ReadObject(e.Result) as ObservableCollection<CategoryType>;

                foreach (CategoryType i in items)

            catch (Exception ex)

//Loading data - tried 2 different ways of adding to my collections - neither worked
foreach (var item in App.Database.Query<CategoryType, Guid>())
Mar 12, 2011 at 1:46 PM

I'm not sure I follow the question.

Sterling will serialize exactly what you provide. Sterling doesn't know about your WCF service or your database. So, if you have a complex object graph, how would Sterling be able to figure out the child objects? You have to provide them somehow. For examle, if you have a parent with a list of children, the only way for Sterling to serialize a child would be to have access to that child. Having the key in your object won't help Sterling, because Sterling has no idea what to do with the key. You would need to populate the child objects.

You don't need to duplicate data - if you have children shared across parents, you could fetch the children separately, compose them to the parents, and save, but Sterling can only handle the data you provide/describe to it.

Mar 12, 2011 at 1:47 PM
Edited Mar 12, 2011 at 1:56 PM

I should have noted that my classes are POCO classes originating from Entity Framework generated usingT4 Template - so the classes have both a reference and a foreign key e.g. Customer and CustomerID or Task and TaskID.  Maybe I am just thinking about all of this in a relational database way.  I'm guessing that the answer to my question is going to be that I do have to download the full object graph from my WCF service - but from then on Sterling will handle things for me in relation to loading referenced objects.  And maybe also I should be excluding the foreign key field itself from the Sterling table definition i.e. exclude CustomerID & TaskID in my earlier example.

Mar 12, 2011 at 1:48 PM

Correct - you want to load the graph, but you can call the various pieces and assemble them separately if you like. As long as Sterling knows the definition and key, Sterling will handle it from there on out.

Mar 12, 2011 at 1:53 PM

Hi Jeremy - thanks for your reply confirming my thinking - our posts crossed in cyberspace.  Much appreciated - David.


Mar 12, 2011 at 2:42 PM
Edited Mar 12, 2011 at 2:49 PM

I'm still struggling with this a bit.

I have a Task that has a Category that has a CategoryType.

When I retrieve the Categories I include the CategoryType.

When I retrieve the Tasks I include the Category.

However if I then look at a Task that is loaded from the database it includes the Category, but not the CategoryType related to that Category.  I know that I can resolve this by including the Category.CategoryType when retrieving the Tasks - but should I really need to do that?

Mar 12, 2011 at 3:01 PM

I think there is something else going on here.  I need to debug further.  Are you able to confirm that my scenario described should work without needing to include Category.CategoryType when retrieving the Tasks?

Mar 12, 2011 at 3:12 PM

I'm not sure what you mean by "retrieving the tasks."

If you save a task with a category with a category type, then when you load the task, Sterling will also load the category AND the category type.

If you save a task with a category that does not have the category type set, then Sterling will not be able to reload the category type.

Mar 13, 2011 at 8:55 PM

By retrieve I mean download from my WCF service.  I will use the term download to make it clearer.

So my scenario is

  • Download the Categories including the CategoryType - save those into Sterling.
  • Download the Tasks including the Category - save those into Sterling.   Not explicitly including the CategoryType at this point because the Category with CategoryType already exists in Sterling.

Shouldn't this scenario now give Sterling enough information to include the CategoryType when loading\querying a Task?

If not then it seems that I have 2 alternatives when downloading from my WCF service

  1. Include the full object graph - which means in my Linq statements that compose the data for my WCF service I must make sure that I include every possible reference to the fullest nesting level.
  2. Just download the data for each table from my WCF service and then find a method to recompose the data, with references, prior to saving it into Sterling.

Thanks for your patience.

Mar 13, 2011 at 9:24 PM


Sterling doesn't try to second guess what you are doing. It takes you literally and does exactly what you ask it to. So, when you have no category type in the category, Sterling assumes you are asking it to wipe out the type. You are issuing a save, and the save is saving the Category as well, and the Category has no type so Sterling clears that - it's exactly what it sees.

This is easy though when setting up the data. As you load and save your categories, just keep the collection around. When you get the tasks, do this:

ObservableCollection _catagories;

// at some point you loaded these and saved them
// now for each task, you can pull the full reference back:

var keys = from c in CurrentTask.Categories select c.CategoryId;
foreach(var key in keys)
    var category = (from c in _categories where c.CategoryId == key select c).FirstOrDefault();

You're basically taking in the "shallow" version of the category that comes and pointing it to the deep one, and the save will work as expected.


Mar 13, 2011 at 9:31 PM

Aha - now I understand what is happening.   That makes complete sense.  I will give your suggested method of implementation a go.  Thankyou.