Hello,
Is there any way to remove a child completely from a collection, without moving the child to the deleted list?
Thanks,
Jimmy
You can do so; something like this was asked recently because the poster wanted to move the child from one collection to another. See this thread.
Out of curiosity though, why are you looking to do this?
Thanks for the link, I think I can use the directions there.
In my application (click once win form) when I'm saving, I create a new collection with the children that can be saved. I save the collection with the cloned children and then put the saved children back into the original list. This works very good :)
I do it to avoid sending the whole collection (could contain 1000 children) back over the wire when only updating 1-3 children. I'm saving the changed children on every row change.
Okay, the reson for removing childring was a test, where I would see if the child was updated on the server by another user, before trying to update it. If it was changed, I would not save it (and remove it from the collection of children to be saved) and notify the user that it was updated by someone else.
I hope the above ramblings made sense :)
That's a different problem then. You should look at the Csla.DiffGram sample in the Samples download (cslanet\cs folder), which illustrates how to do diffgram updates of a list - so the list isn't sent to the server for insert/update operations, but instead only changed items are sent over.
I don't remember if I made the sample do delete operations or not - but you can check. The same basic principle should apply.
That's a different problem then. You should look at the Csla.DiffGram sample in the Samples download (cslanet\cs folder), which illustrates how to do diffgram updates of a list - so the list isn't sent to the server for insert/update operations, but instead only changed items are sent over.
Does this work even when said list is a child of another object? (Sounds like a very neat trick if it does... :)
It absolutely works when the list is a child of another object.
The idea is simple, though the actual implementation isn't always simple.
The idea is to build a diffgram that contains all the data necessary for some server-side code to do insert/update/delete operations on some of your objects. All without ever sending the objects over the wire - just the minimum data needed.
The sample implements a visitor pattern, so every object in your object graph is visited and is asked whether it needs to send any data to the server as part of the diffgram. If so, the object gets to send whatever field values it wants to provide. If not, the object is not included in the diffgram at all.
The sample has an order with line items. The idea is to edit the line items and click save. The diffgram ends up containing the order id (foreign key) and the fields from each child object in the collection that's been changed. Oh, and of course the collection itself is represented in the diffgram, because something needs to contain the child objects.
The hard part isn't in the sample (because I needed to leave something as an exercise for the reader 
) - which is to take the bits and pieces of data that are in the diffgram and translate that into actual database updates. That's done in a command object, and of course could be quite complex (or simple) depending on how complex your object model and/or database might be.
The server-side code in the command object can update the diffgram too, and the diffgram comes back across to the client and is merged back into the objects - again by using the visitor pattern - asking each object in the graph if it wants its data back (so to speak).
I suppose - to sum up - this diffgram technique is great for the case where you have thousands of objects in an object graph, and only a few of them are changed.
If you have just a few objects - a couple dozen or something - in your object graph I think you'd have a hard time justifying the complexity and losing the mobile object benefits.
Generally, I'd recommend doing a standard mobile object implementation, and only incurring the complexity of using a diffgram if you hit perf issues.
Another problem was pushing the returned child object(s) into the binded list in the UI (when saving async) - The edit level would go out of sync and the application would break. But what I realized from the diffgram idea, is to only update Version (the timestamp) for each saved child object.
Yes, the diffgram results come back to the client and are merged into the existing object instances, so things like edit level are typically unaffected.
The diffgram sounds (very) interesting, but I have some cases now where I cascade changes to child objects from the root as part of the server side update. So, at the time of the Save() call, only the root is dirty, but then server side some of the child objects may end up being changed.
This is a specific case that I could probably figure out how to handle, but in general the problem is that many of the existing DataPortal_Update implementations were written with assumption that the entire object graph was available. So, it seems like with the diffgram approach you don't have as much knowledge server-side as you did before. This is probably not an issue 90%+ of the time, but it's something to consider.
Copyright (c) Marimer LLC