UpdateModel issues

I am having issues using UpdateModel. Now sure if I am missing something or not.

I have a view model that is being returned for the update. When I call UpdateModel, the email in the view model is null, but the email in the LightSpeed model is updated to "". This then calls email validation and says the email is not valid.

I am not getting bools to update when calling UpdateModel either.

Any ideas would be appreciated.

Ill look at setting up a local repro here and get back to you once I have debugged this here. In terms of the bool issue, which version of LightSpeed are you running? And is the posted value on/off, true/false or something else?

Thanks!
Jeremy

I am using the version 4 that I downloaded yesterday (not nightly build). I don't have the number handy.

The posted value is coming in as true/false. That is what is confusing me. I can do LSmodel.boolval = myviewmodel.boolval and it will change the LightSpeed model value, but just calling UpdateModel does not.

Thanks for the help.

Jeremy,

Any luck on this? I have a simple little project that I could send you that shows the issue with the bool and email not being updated correctly.

Thanks

Hi Craig,

I believe we have tracked down the cause of the bool issue and we should have a fix committed into the 5.0 nightlies for this tomorrow. I will update this again once this has been merged in. In terms of the email issue are you able to send through the repro please and I can have a look into this.

Thanks!
Jeremy

Jeremy,

I tried uploading a zip of the project, but it failed each time. Is there another way for me to get you the project?

Yes you can email this to us - support at mindscape.co.nz :)

Thanks!
Jeremy

Jeremy,

Just checking if you go the email with the project?

Thanks

Yes I have received this and will be looking into this today - thanks! I will get back to you with an update after I have had a look into this :)

Jeremy

Hi Craig,

Email is being updated to the empty string since that is what is being posted (e.g. inspect Request.Form["email"] with a debugger attached). We dont assume the empty string means null, we assume the lack of a posted value means null. The default model binder has different behavior here which is why you are seeing it have a null value.

Given you are already unbinding to the view model you could use unitOfWork.Import instead which will do an upsert on the existing entity. e.g. instead of calling UpdateModel use:

uow.Import<Parent>(editModel);

This will update the already loaded parent instance and will use the values as per the editModel instance.

Jeremy

Jeremy,

Cursory testing shows this is what I was missing/looking for.

Thanks for the response.

Craig

Jeremy,

The bool is working now, thanks.

Couple of questions here though.

If I pull in the model from the database and it has a lock version of 1, then I change the lock version to 2 in the database, then post my changes so that the incoming value from the post has a lock version of 1 in editModel. After the following code, it updates with a lock version of 1. Is this expected behavior?

uow.Import<Parent>(editModel); 
uow.SaveChanges();, 

In my previous code that I sent, when I called UpdateModel after changing the the lock version in the database, it would give me an error. I am not getting the same behavior now. It is now saving with the current lock version and not checking the lock version coming in form the post.

Thanks, Craig

Hi Craig,

Yes - LockVersion will not be updated and the original value loaded with the entity will be used which means the only window for a concurrency failure will occur if the value in the database changes in between when you load the entity first in that method until when you call SaveChanges and the UPDATE statement is executed since that will include a clause checking the LockVersion to guard against a change.

We have updated the LightSpeedModelBinder to now be consistent with this since it shouldn't have been unbinding managed fields (e.g. LockVersion, CreatedOn)

Jeremy

Jeremy,

This makes sense.

What is the prefered method to use lock version in a situation like the code I gave you? Or do I need to manually check before I call SaveChanges?

Thanks, Craig

You shouldn't ever need to update this yourself :) LightSpeed will increment it automatically as part of persisting any changes.

Jeremy

Jeremy,

Looks like I did not ask my question quite right. Let me add a little context to my question based on a web application.

User A pulls the data into their browser, but does not update immediately. In the mean time user B pulls the data into their browser, makes changes and saves the changes. Now user A makes a change, saves the change, and overwrites user B’s changes. With the previous version, this scenario would throw a concurrency error when user A went to save the changes. My question is about how we handle this scenario now. Do I need to manually check the LockVersion prior to saving the changes?

Thanks, Craig

Hi Craig,

You will get an optimistic concurrency exception if the LockVersion doesnt match (e.g. two concurrent threads both load the same copy of the object, thread 1 saves first, thread 2 will throw an exception because the LockVersion in the database has already been incremented by thread 1).

You will see a message like "An optimistic concurrency violation was detected while attempting update or delete of table [Parent]" when this occurs.

Jeremy

Jeremy,

This is a web based application, so it is stateless and not like a windows application.

You are describing is how this worked previously. I designed my application based on how this used to work and now I am not getting the concurrency checking. This has to do with the way the model binding works now. It currently uses the value that it gets from the database when I call UnitOfWork.Import and does not use the original lock version value. If I originally got a lock version of 1, but the lock version is now 3, the Import will use the 3 and say everything is fine and do the update. With this new behavior, it is virtually impossible to get a concurrency error.

My question is how are we supposed to use this new functionality to check the version of the record?

Thanks, Craig

Gotcha - in this case you will need to check this manually check for this. Unless you need specific detection and error information raised for this you could just handle this when you fetch the parent instance initially by adding a LockVersion == editModel.LockVersion clause into your query. The null result will then cover a non existant Id or mismatched LockVersion.

Jeremy