Well. Looks like I've narrowed it down to a workaround. Firstly, the issue has nothing to do with EF. Embarrassingly, it was client side, and I totally blame my learning two technologies simultaneously, in combination with the irresponsible usage of the word/classname 'Entity' by RIA Services, for my confusion. ;)
The problem seems to be when using [Composition] with RIA Services with the RadGridView. When I press escape to undo the creation of a new row, it throws the exception I've been getting when it tries to remove the entity from the SourceSet. The problem was not happening where composition was not being used. I made some changes to remove the usage of composition on this particular page and now pressing escape to undo a new row insert works. I've cross posted this to the OzSilverlight in case someone there is interested. Surely I can't be the only person to want to undo an insert on a composition service call? Also, a search for this error in combination with RIA Services, rather than EF actually turned up this post -> http://forums.silverlight.net/forums/p/215248/511408.aspx Amazing what you get when you actually search for the right thing, hey? *blush* As temped I was to not post this, someone else might actualy benefit so meh, I'll take it as a learning exercise. cheers, Stephen p.s. I'm just happy to be here. On Mon, Mar 28, 2011 at 1:08 PM, Arjang Assadi <[email protected]>wrote: > In that case, I suggest to create a temp layer that translates from EF > to datatable, use the grid, and trnanslate back to EF, assuming > DataTable would not have the same issue. > > In above statement substitute X in place of DataTable where X could be > Linq Objects, BindingList of Business Object etc. > > Hope that helps to side step the issue. > > Regards > > Arjang > > On 28 March 2011 15:05, Stephen Price <[email protected]> wrote: > > Yep, totally understand. > > > > Not using EF isn't an option for this project as it's already being used. > > That leaves finding a work around as the best option. Sort of like > jumping > > off the cliff then having to deal with the fall on the way down. maybe > not > > the best analogy. The sudden stop at the bottom has a similar amount of > pain > > associated with it at times, so perhaps it is a good analogy. :) > > > > On Mon, Mar 28, 2011 at 11:43 AM, Arjang Assadi <[email protected] > > > > wrote: > >> > >> Stephen, > >> > >> After having burned many hours with EF trying to understand "why"s, I > >> have come to the conclusion to find ( EF or non-EF ) workarounds > >> instead. > >> > >> I have even seen the champion of EF, Julie Lerman post to MS > >> newsgroups questioning the rational behind the very same behavior I > >> was trying to understand ( it was about using EF in an N-Tier > >> disconnected way). > >> > >> I guess the question one ends up asking themselves boils down to > >> whether they are trying to use EF to accomplish some task or doing EF > >> to understand EF itself. > >> > >> Having said that, EF does solve many problems but at the price of > >> introducing a different types of problems. Question is which problem > >> set one wishes rather be solving. > >> > >> Regards > >> > >> Arjang > >> > >> > >> > >> On 28 March 2011 14:24, Stephen Price <[email protected]> wrote: > >> > Hey there, > >> > > >> > Are there any EF gurus about? > >> > This is a further email about the issue I posted recently where > pressing > >> > escape to undo a new row on a RadGridView is throwing an exception on > >> > some > >> > entities but not others. > >> > > >> > I've tracked down a difference but can't seem to find anything about > >> > SourceSets. > >> > > >> > > >> > > >> > public void Remove(object value) > >> > { > >> > T entity = value as T; > >> > if (entity != null) > >> > { > >> > this.Source.Remove(entity); > >> > if (this._addedEntities.Contains(entity)) > >> > { > >> > this._addedEntities.Remove(entity); > >> > this.Source.SourceSet.Remove(entity); > >> > } > >> > } > >> > } > >> > > >> > > >> > This is the code i've decompiled to see what's happening... > >> > > >> > the line with the sourceset.remove is throwing an exception because > the > >> > sourceset is null. I guess you could say that's a bug? I mean it's > >> > checking > >> > if _addedEntities contains the entity before it removes it, but does > not > >> > check if the SourceSet contains the entity before trying to remove it. > I > >> > don't know enough about the EntityFramework to know what a SourceSet > >> > is... > >> > may just be an internal only structure or something else? > >> > > >> > > >> > int index = -1; > >> > if (entity.EntitySet == this) > >> > { > >> > index = this._list.IndexOf(entity); > >> > } > >> > if (index == -1) > >> > { > >> > > >> > > throw new > InvalidOperationException(Resource.EntitySet_EntityNotInSet); > >> > } > >> > > >> > > >> > Inside the remove (second code snippit above) it checks if the entity > is > >> > not > >> > in the set and throws an InvalidOperationException. > >> > > >> > By that, I'm taking it that the entity not being in the SourceSet is > an > >> > exceptional circumstance. Just can't figure out what that means, right > >> > now. > >> > > >> > Feel like i'm learning to firewalk here :) > >> > > >> > cheers, > >> > Stephen > > > > >
