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
|
I am new to C# and lightspeed. I am trying to an update method, but I am not real sure what the best way is to go about it. I found an older post about using reflection: http://www.mindscapehq.com/forums/thread/3628. I can see how to use System.Type class to get a lot of information about the Entities and the classes created by lightspeed.
My original thought was to try to compare the uowUser to user and if their values do not match then update the uowUser, but I don't really see how. Any help would be appreciated. |
|
|
After your find, uowUser is the data from the database, user is your new data. So you might write:
|
|
|
I see what you are saying about user is the new data. I was not assuming that the new user object had all fields filled out. If that is the case couldn't I just:
and be done with it? |
|
|
Depends. If the user object originally came from the database and the Id (i.e. the Lightspeed int key value) is a value in the database, then you can, which FindById implies that it is. The more generic case is where the user is a new object and may have the same Name (or other identifier) as a record in the database. You want to update the current record. So uowUser will have a valid int Id while the new entity user will have an Id of 0. Getting the uowUser by a search on the Name and setting it to the new object user, with an Id of 0, will save the user object as a new record. Getting uowUser, setting user.Id to uowUser.Id, setting uowUser to user and SavingChanges will update the record. Just depends on how the Id is modified, or not. |
|
|
No this wont achieve the same result. With uowUser = user you are just re-assigning the reference held by uowUser to be the same as user, it will not assign the data in user to the object which was held by uowUser. The second problem with this approach is user is not being tracked by the UnitOfWork (the entity loaded and assigned to uowUser is though) so in calling .SaveChanges() nothing will occur as nothing has changed. If you want to add the user instance directly you could attach it to the UnitOfWork e.g.
But its likely you want to import the user instance (e.g. update existing or create new) so you can use the .Import method to handle this, e.g.
|
|
|
Yeah, I noticed after my previous post that nothing was happening on save changes. The Import method does update the user object/entity as you suggested. Thanks for your help! I had two child entities eagerly loaded with my user. All three objects were modified and all three had an Entity state of "Modified". Unlike the User, the other entities were not updated in the database upon save changes. When I created the child objects they were attached to the user and were saved just by adding the user to a unit of work. Does the update not go through the object graph updating anything marked as "Modified"? |
|
|
UPDATE: When I used "attach" the child entities were updated with the parent. I tried looking at the API but there isn't much detail there. Can you explain the difference between attach and import for me? |
|
|
Attach is used for attaching entities to a UnitOfWork, primarily this is used to allow you to detach entities from one UnitOfWork scope (using .Detach) and then attaching them to another for longer running scenarios. If there is an existing entity of that Id in the identity map for that UnitOfWork it will be replaced by the attached entity. Any children of the entity will also be attached to the UnitOfWork. Import is used for attaching arbitrary objects to a UnitOfWork mapping them back to an entity (it can also be used for entities since they are also objects), if the object has an Id field then we check for an existing entity of that Id first (e.g. in the identity map and then the database). The existing entity we load is then updated with the values held on that object which match value fields on the entity (e.g. think of a reflection based update of property values). Import only covers the specific object being imported and does not attempt to traverse any relationships.
|
|