title: SIlverlight 5 RIA composition child entity delete
body: <p>I'm using a custom library which generates the DAL for me similar to Entity Framework but not identically and am having a problem using it imposed by RIA.  My problem is that the custom DAL produces an IsPersisted property which essentially identifies if the entity has a corresponding DB record.  The key part of the delete code looks like ...</p>
  
  <pre><code>if(this.IsPersisted)
      dataAccessor.Delete();
  else
     throw new NotSupportedException("Delete not supported on unpersisted entities.");
  </code></pre>
  
  <p>The problem comes in when I use RIA to generate the medium between client and server.  I have a parent class with a child composition property like</p>
  
  <pre><code>class Parent{
      ...
      [Include,Association("Parent_Child","ParentId","ParentId",IsForeignKey=false), Composition]
      public List&lt;Child&gt; Children{get{return (_children = _children??new List&lt;Child&gt;());}}
  }
  </code></pre>
  
  <p>In the client code, if I then use <code>parent.Children.Remove(child);</code> the correct entity action is relayed to the server but for the <code>IsPersisted</code> flag gets changed to false when the change set is generated which in turn causes a <code>NotSupportedException</code>.</p>
  
  <p>I've done a lot of digging and exploring.  After examining the actual network traffic back to the server I see that the ChangeSet being sent to the server actually contains the flaw.  It correctly exposes the original entity and values but then in the Delete segment of the changeset I can see the same entity (verified by the same identity) specified again as OriginalEntity but this time all the values are empty except the ID. </p>
  
  <p>If I trace the deserialization of the ChangeSet, I can see it actually create two separate instances of Child, first populated correctly, then again zeroed out.  The ChangeSet then only holds the zeroed out version of the child.  </p>
  
  <p>Any ideas as to how to fix what RIA is sending up the wire?</p>