title: DbEntityEntry.OriginalValues not populating complex properties
body: <p>I'm writing an audit trail from snippets of code found online. On the call to my SaveChanges function I loop through all the modified entities registered with the Context and build log entries from their changes.</p>
  
  <pre><code>foreach (DbEntityEntry modifiedEntity in this.ChangeTracker.Entries().Where(p =&gt; p.State == System.Data.EntityState.Added || p.State == System.Data.EntityState.Deleted || p.State == System.Data.EntityState.Modified))
          {
              // For each changed record, get the audit record entries and add them
              foreach(AuditLog x in GetAuditRecordsForChange(modifiedEntity, userId))
              {
                  this.AuditLog.Add(x);
              }
          }
  </code></pre>
  
  <p>When I then try to access the original values of the modified entity, all the scalar properties are populated but the complex ones don't exist (property count will be say 6 instead of 8). I then call <code>ToObject()</code> to build the object in its original state but obviously the complex properties are all nulls.</p>
  
  <pre><code>modifiedEntity.OriginalValues.ToObject()
  </code></pre>
  
  <p>This only happens with <em>some</em> of my domain objects, and those objects always show as proxies after the <code>ToObject()</code> call whereas (I'm not sure why) but the ones that don't have proxies created for them by entity, their complex properties populate fine. When I'm using the POCO proxies as normal throughout my application, lazy loading works fine on them.</p>
  
  <p>I've noticed that if I make a change to one of these complex properties that are not populated as part of the OriginalValues data, the object's state doesn't get changed to Modified, this makes sense as change tracking compares the original values to current to see if it's changed. What <em>doesn't</em> make sense is that the data is still persisted on SaveChanged??</p>
  
  <p>EDIT: I've just noticed, the model object that <em>does</em> populate its complex properties, the complex property in question is (by convention) considered a 'complex type' by Entity i.e no primary key.</p>
  
  <p>Any ideas?</p>