This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, we have a client-server app, using WCF, LS 4, and a distributed UoW. We are observing a very weird issue. We have an entity called Path that contains a collection of Segments. When a Path is created, it gets automatically an initial Segment on its collection. 1) We have seen that if the Path is not saved (it´s entity state is new), and we call uow.Remove over it, then the Segment inside the Path (which was New too) does not get marked as Deleted. We have to call uow.Remove over it by hand, and we have discovered that when we call uow.Remove(segment), the Segment is removed from the Path.Segments collection. 2) Then, if the Path is created (with the Segment), then we call uow.Save, and then we call Remove over it, the same happens: we have to call Remove over the Segments manually (and they get eliminated from the collection as we call Remove). 3) And then, if we get the Path from the DB (with a Segment), and we call uow.Remove over it, the Path gets marked for Deletion but not the Segment. And if we call Remove over the Segment, it gets marked for Deletion, but it´s not removed from the collection. I supposed that as this is a 1-N relation, removing the Path would remove the segments, when we call uow.Save, but all three situations do strange things. Case 1 I have to call Remove on Path and Remove on the Segments, or I´ll get an exception when saving (Could not commit changes, no useful info :( ). Case 2 I have to call Remove first on the Segments and then on the Path, or I´ll get an exception if I try to remove the Path first (NullReferenceException). Case 3 works as expected: I remove the Path and when I save the Segments are removed too. It looks like there are some issues here, but I am pretty lost really. Regards! Vicente |
|
|
I´m attaching a test case that shows the problem. It has 6 different main entry points (1a, 1b, 1c, 2a, 2b, 3a), that show different scenarios and what happens in them (sometimes LS works, sometimes LS crashes, sometimes the entities are removed from the collection, sometimes aren't). I hope this helps finding the issue (or maybe we have a concept problem here). Regards! Vicente |
|
|
Thanks for the test cases - much appreciated :) The issue is around delete cascading so this is a bug as it should behave as with a local UnitOfWork. We will look at getting this fixed and will update you once we have something in the nightlies.
Thanks! Jeremy |
|
|
Great to hear Jeremy, I'll keep an eye on this :) Regards! Vicente |
|
|
Hi Vicente, Just an update on this, I have made some updates which I believe should cover all the issues you were experiencing. Its not likely to make it for tonights nightly build but we should have this in for tomorrows build. Will update you tomorrow on this.
Jeremy |
|
|
Great! Thanks a lot for this. As soon as we try it I'll update here about the results. |
|
|
Hi Vicente, Updates are in for tonights nightly build. Let us know how you get on.
Thanks! Jeremy |
|
|
Hi Jeremy, the issues I reported are fixed with the nightly build from 9th August :) That´s the good news, but the bad news are that something has broken and I´m not sure exactly what. In the app, we recover lists of entities, and then bind those lists to a grid control from Telerik. This was working perfectly until today when I updated to the 9th August version. Now when I try to add a new entity to that list, I get a NullReferenceException with the following stacktrace:
at Mindscape.LightSpeed.Entity.BeginEditInternal() at Mindscape.LightSpeed.Entity.BeginEdit() at Mindscape.LightSpeed.Entity.BeginEditInternal() at Mindscape.LightSpeed.Entity.BeginEdit() at Mindscape.LightSpeed.Entity.BeginEditInternal() at Mindscape.LightSpeed.Entity.BeginEdit() at Telerik.Windows.Data.QueryableCollectionView.<BeginEditItem>b__0(IEditableObject i) in c:\TB\101\WPF_Scrum\Release_WPF\Sources\Development\Core\Data\Collections\QueryableCollectionView.Editing.cs:line 458 at Telerik.Windows.Data.QueryableCollectionView.ExecuteAs[T](Object item, Action`1 action) in c:\TB\101\WPF_Scrum\Release_WPF\Sources\Development\Core\Data\Collections\QueryableCollectionView.Editing.cs:line 476 at Telerik.Windows.Data.QueryableCollectionView.BeginEditItem(Object item) in c:\TB\101\WPF_Scrum\Release_WPF\Sources\Development\Core\Data\Collections\QueryableCollectionView.Editing.cs:line 458 at Telerik.Windows.Data.QueryableCollectionView.EditItem(Object item) in c:\TB\101\WPF_Scrum\Release_WPF\Sources\Development\Core\Data\Collections\QueryableCollectionView.Editing.cs:line 343 at Telerik.Windows.Data.DataItemCollection.EditItem(Object item) in c:\TB\101\WPF_Scrum\Release_WPF\Sources\Development\Core\Data\Collections\DataItemCollection.Editing.cs:line 285 at Telerik.Windows.Controls.GridView.GridViewDataControl.set_RowInEditMode(GridViewRow value) in c:\TB\101\WPF_Scrum\Release_WPF\Sources\Development\Controls\GridView\GridView\GridView\GridViewDataControl.Editing.cs:line 40 If I revert to our older version of Lightspeed (4.0.580.17988) everything works fine. Not sure if that helps a lot, it's the best I have right now :S Regards! Vicente |
|
|
Thanks for the update! Would you be able to create a small repro which we can use to isolate the issue? It would appear that the error you are hitting is unrelated to the distributed bits since that exception is being generated from within the main framework code but there have been quite a number of changes in between the two versions you are using so its a bit unclear what that might be related to without more detail unfortunately.
Jeremy |
|
|
I´ll try to build a repro tomorrow and see if this happens also with a normal Grid instead of Telerik grid. I´ll update it here when I have it ready. Regards! |
|
|
Hi Jeremy, I have not been able to build a repro so far (seems to be a weird threading issue). The only extra information I have is that is something that changed between the 2th and 9th of August nightly builds. Is there any way to get all the nightlies between both dates so I can tell in which one is the change (maybe it can help finding the problem). Regards! Vicente |
|
|
Yes, certainly could. If you can send me an email to contact at mindscape.co.nz we can arrange getting these made available for you.
Jeremy |
|
|
Hello Jeremy, I have tried all the builds and the change that broke things here happened the 8th of August. Maybe that with the error can help a little? (I have not been able to build a repro yet). Regards! Vicente |
|
|
Thanks that does help a lot in narrowing it down - from the activity on that date the only real candidate will be around changes we made for partial updates, so we can have a look at trying to reproduce this here.
Jeremy |
|
|
Great news Jeremy, I'll keep trying to build a repro here. |
|
|
Hi Vicente, We've had a dig around and nothing is jumping out based on your stack trace. Can you confirm:
That should help narrow it further but, as mentioned, ideally if you had a small repro that would be awesome. Kind regards, John-Daniel Trask |
|
|
Hi John, I've checked and: - the entity is not using UnversionedPartialUpdateAttribute - the entity is marked with the Serializable attribute. This happens on the client side of a WCF app (the entity was recovered using a DistributedUnitOfWork, so it's attached). I continue trying to build the repro, but no idea why it doesn't happen on my small app yet. Regards! Vicente |
|