Yes i absolutely agree with you. It should roll back all the changes since the last load and this is the right behavior. An other thing is about the collections of every object maybe have. A client has a collections of orders. When i reject changes for a
client do i expect changes to be rejected for orders also? Well i think things are getting a little bit hard here and i guess you have many things in schedule to implement. I will agree with what ever you think the important part is the reject changes per
object. Object Tree reject changes can wait for now.
Plus i would like to give you an idea about this feature. If it is possible for each object to have
a) a property with the changes that happened to it since the last load. This property could be a hash table with field name and original value
b) and also an enumerated state property (Modified, Not Modified, Deleted).
Lately i was working on a big project with very big business entities and forms with many text boxes. There were times where the user wanted to see the initial value of a field and undo only that insteed of the whole object.
I spent all the night watching your videos, reading the documentation and posts from users. So i found out that each object exposes a set of events for changes so i could still accomplish this functionality by handling this events but the mechanish
of tracking the change event from all the objects loaded is hmmm not a good idea to implement if there is an other way. I think the object itself must track its changes. Anyway it is not a must feature, just an idea.