NullReferenceException calling Single or First LINQ Extension Methods

Hello,

See attached model.  The following code snippet (at line partyUnitOfWork.People.Single) throws a null reference exception deep inside LightSpeed.

                    var target = new Person();
                    target.FamilyName = "Bloggs";
                    target.Addresses.Add(new EmailAddress {Value = "joe.bloggs@thembalaw.com"});
                    target.SecurityTokens.Add(new PasswordSecurityToken {Password = "Password123"});
                    partyUnitOfWork.Add(target);
                    partyUnitOfWork.SaveChanges(true);

                    target = partyUnitOfWork.People.Single(p => p.FamilyName == "Bloggs");
                    Console.WriteLine(target.Id);

The same thing happens when I call SingleOrDefault, First, FirstOrDefault with or without an argument. This works fine with EF 4.1

Thanks,

Werner

Just enumerating through the People collection causes the NullReferenceException to be thrown.  So this fails:

foreach (var person in people)
{
  // do something
}

Werner

The error is being raised because in your model you have specified a Discriminator on Person using the field "Type" and the value 1 but the Party entity does not have a Type property. I imagine this is just a difference between how we handle inheritance through use of the Discriminator attributes vs EF if you are using the model and code.

The error message that is produced isnt particularly helpful though so I will add an item to our backlog to see if we can do something more sensible at runtime when we initially load up the model to detect this kind of issue and throw a more meaningful error for you.

Thanks!

Jeremy

Hi Jeremy,

Thanks for the response. I'll go ahead and add the "Type" field and see if it solves the problem.  

It comes as a surprise that I need to explicitly deal with discriminators in the model.  Since other frameworks (EF, Django, Rails) take care of this automatically, so I didn't think that its necessary.  

I trust you guys know your databases and how to best implement inheritance and define discriminators in a optimal and portable fashion.  So I'm not sure why I should to manually configure each discriminator for each subclass.  I'm more likely to follow your suggestions than invent my own unique scheme. But I do understand that there are some that want to implement their own schemes, especially with legacy databases; I'm just not sure someone wants this level of flexiliby from the word "go".

I'm impressed with the level of support.

Werner

One tip that may help is that if you set the Discriminator setting on the base class before drawing any inheritance arrows, we will copy that to each inheritance arrow as you draw it*.  This saves you from repeatedly entering the discriminator name and type on each arrow -- a feature which, as you anticipate, almost nobody uses in practice.  If we had our time again we'd probably get rid of this unnecessary flexibility, but failing that, we hope that the 'enter it once on the base class' trick saves you a bit of effort!

* Note that if you draw any arrows before setting the Discriminator on the base class, they will not pick it up when you do.  You'll still have to fix them up manually.