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
|
LS Version: 4.0.524.17831 I'm having issue with lightspeed updating an entity that contains a value object, add seems to be fine so I guess LS is generating the update sql with the name of the value object instead of using is properties. eg. if (profile.Id > 0)
{
var query = new Query
{
EntityType = typeof(Model.Profile),
Identifier = profile.Id, When calling _uow.Update I get the following exception: Could not find field [Location] on model [Profile] Is there a solution to this? Thanks in advance. |
|
|
Thanks for drawing our attention to this. There will be a candidate fix in the next nightly build. |
|
|
That's great, cheers. Thanks for the prompt response! |
|
|
LS Version: 4.0.1086.19459 Update in nightly build works, thank you. Is it by design that if we have "Soft Deletes", "Track Create Time" and "Track Update Time" on for entity, executing an update this way will require you to populate the values?
I am working with a ViewModel which I doesn't need these fields, so when I map to my Model.Profile entity these fields are DateTime.Min. Is it possible to have _uow.Update(query, profile) exclude CreatedOn and DeletedOn from being updated and set UpdatedOn to the current date? |
|
|
Handling special fields in updates is a bit tricky. The particular problem is LockVersion. Given this problem, and the fact that IUnitOfWork.Update bypasses all other entity guarantees such as validation, we have rather adopted the philosophy that Update is a pretty raw 'write this stuff to the database' API. So at the moment this does mean that the CreatedOn, UpdatedOn, DeletedOn and LockVersion fields must be populated with the values that you want to see in the database. I agree this isn't ideal and we should probably review this to see if we can improve the behaviour. In your specific case though, since you are updating only one entity, you might do better to use a normal entity update rather than a bulk update. This would allow LightSpeed to set up the special fields correctly. Given that you already have a 'fake' entity that you are using as a viewmodel, the easiest way to do this is using IUnitOfWork.Import:
This should be all you need to do so it will actually be shorter than the bulk update version! |
|
|
I see what you mean, makes sense. Thanks for the explanation. IUnitOfWork.Import Awesome support by the way, very quick responses! |
|