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 seen that when calling SaveChanges over a DistributedUnitOfWork, newly created entities are not updated from new to the Default EntityState. This means that if the user clicks two times save, well, we get two times that entity in the DB :S Is there something we are missing, or how should be this be approached? This is using the nightly build from the 6th June, 2011 (not sure if it helps). Regards, Vicente |
|
|
Hi Vicente, Ill have a look into this and let you know what I find - this shouldnt be the case. In the meantime you should be able to avoid this by forcibly flushing the identity map as part of the save by calling .SaveChanges(true).
Jeremy |
|
|
Mmm, I have tried setting true in SaveChanges, but it's not what we need I think. I'm going to explain myself a little better: our app is a WPF app using a long unit of work strategy (in fact, we open it at the start and that's it, it stays open until the user decides to work with another DB or close the app). During the app usage, we query the unit of work for data as the user asks for it, and that data (most of the time EntityCollections) is databinded to our UI. Then, when the user hits Save, changes go well to the DB, but the new entities remain in their New EntityState. Using SaveChanges(true) doesn't change that, the new entities continue to have New as their EntityState. Reading the docs it seems that SaveChanges(true) means that we will get the correct result next time we query the UoW for data, but we are not doing that, we already have the data loaded, binded,... Forcing a full reload everytime the user saves would be very painful :S |
|
|
Just to clarify, the issue is basically that, if you add a new entity, then call: distributedUnitOfWork.SaveChanges(true); // ... Do something else for a while distributedUnitOfWork.SaveChanges(true);
The new entity will get added 2x into the database. It appears that, during the SaveChanges, the EntityState of the new entities is not changed from New to Default, so the next time SaveChanges is called, it happens again. Right now, I'm not sure of a good workaround, and this is causing us major issues, as we are completely unable to hand-edit cleanly (unless we wanted to force a full refresh of all data across the wire every time we allow a user to save, which would be painful from a usability standpoint, as well as incredibly wasteful).
|
|
|
Hi guys, Are you able to send through a small repro of this? I cant reproduce this behavior here. From what you have described it sounds like the entity involved must not be getting associated with the UnitOfWork. The process which is followed on save is to: - Flush the change sets to the server - If there are any errors in actually persisting things at the server you will see an exception thrown by LightSpeed - If there are any communication issues then you will see an exception thrown by WCF - Once we have recieved the response from the server all of the entities known to the unit of work have their identifiers updated as required based on the server side state and the entity state for all entities gets reset back to Default. So given that step 4 isnt happening for you my conclusion would be that the entity involved isnt part of the UnitOfWork - I can certainly track this down furthor with a repro :)
Thanks! Jeremy |
|
|
Hi Jeremy, I have attached a repro case. It's your DistributedExample sample. The important code is here:
//unitOfWork.Attach(story); // If you uncoment this line, code works! section.Stories.Add(story); unitOfWork.SaveChanges(); unitOfWork.SaveChanges(); Debug.Assert(unitOfWork.Stories.Count() == 1); // This will fail if the line is commented I have discovered that attaching the story before adding it to the section fixes the problem. But your own sample was adding the story inline without using a temporal var, so the same was happening there too :) Either way, the behavior looks like a bug. I mean: the entity gets added to a collection, but it's not tracked by the UoW, but it gets saved? If it's not tracked it shouldn't get saved to the DB, and I would assume that adding an entity to another tracked entity collection would track the added entity. If you need more information let me know. Regards! Vicente |
|
|
Awesome - thanks! That was definitely not the result I expected to see :) Definitely was a wee bug relating to how the entities were being gathered for the reset of the EntityState field. Ive added in a fix for this so this will be available in tonights nightly build of 4.0 for you :)
Jeremy |
|
|
Great to hear Jeremy, as usual thanks for your awesome support :) Regards! Vicente |
|