Hello Guys, thank you for your input on this. I'll take a look through that API you're talking about, certainly sounds of interest!
I agree that the current method is inefficient as it requires the entire object branch to be resent to the client however I only opted for this option because I wasn't quite sure how to cope with deletes. Mark, with regards to your recursions solution, that certainly sounds excellent but how would you suggest I deal with scenarios when children are added or removed from a collection, the client needs to be made aware of that however a simple recurse through the modified dates wouldn't do that, you'd have to rely once again on setting a modified flag on the parent object wouldn't you? and then we're still going the route of downloading the entire parent branch to save on the client end. I'm in control of the client application so I can effectively make it sing as we like, if there is a way to manage deleting objects then this recursion over the tress sounds like a perfect solution! However, the client application is not running on ColdFusion so we cant rely on TF at the other end. In an ideal scenario the client would initially download the entire object tree and then subsequent calls to the service would allow it to to track any additions, deletions of modifications of objects within the tree. Like I say, the only reason I've not tackled this before is that I'm not sure how to cope with objects being deleted and how to effectively have the client be aware of that without them having to download and re-save the entire parent tree of that deleted object. Thanks again guys, your help is always invaluable. Rob p.s. in case it makes any difference to your train of thought a great deal of the time the objects are not actually deleted from the object tree, they're just having their relationships removed. On Mar 7, 9:15 pm, Mark Mandel <[email protected]> wrote: > Thanks Brian, forgot my * own * API there. > > Brian is right - check > out:http://docs.transfer-orm.com/html/transferapi/transfer/com/Transfer.h...() > > (This is only documented in the API docs, as it's a fair edge case > that people need to do this). > > Mark > > > > On Sun, Mar 8, 2009 at 8:03 AM, Brian Kotek <[email protected]> wrote: > > One option might be to look at the way the Visitor pattern is used by > > Transfer and write your own Visitor. Then you can find the objects that have > > been modified and walk up or down the object graph from there and do > > whatever you need to. > > > Also, if I understand this correctly, if a parent object that has a large > > graph has any one of it's children changed, you have to resend the entire > > graph again? Isn't that rather inefficient? Or is that just want the clients > > are requiring? > > > On Sat, Mar 7, 2009 at 3:48 PM, Mark Mandel <[email protected]> wrote: > > >> I'm curious as well - > > >> Why not just traverse the entire object graph, check lastModified (or > >> your boolean flag), pick up what has been changed, stick it in an > >> array, and then pass it back over. > > >> Then you're just dealing with a recursive algorithm to go over the > >> tree, a simple yes/no as to whether or not it needs to be passed back, > >> and you're golden. > > >> If you know you are going to recurse the entire object graph, then you > >> don't need to worry about parent's being set to 'modified', you just > >> send the bits that need sending. > > >> Or does that not fit as an option? > > >> Mark > > >> On Sat, Mar 7, 2009 at 9:43 PM, Sir Rawlins > >> <[email protected]> wrote: > > >> > Hey Brian, > > >> > Thanks for getting back to me on this. > > >> > I know what you mean about the modified date and this is effectively a > >> > similar principle to what I'm running at the moment. I'd be keen to > >> > see if there is a better way of organising what I currently have but > >> > at the moment the main challenge comes from the fact that we're > >> > passing a composed tree of objects over the service. If we were just > >> > passing a bog standard collection (1 level deep) over the webservice > >> > then that approach would be very simple to implement however we're > >> > passing an array of objects, each of which then contains another array > >> > which then contains another array etc. so you have a fairly > >> > substantial tree to consider, then say one of the objects at the > >> > deepest level becomes modified, then as the only way to access those > >> > deepest objects through the service is to download its parent I set > >> > the modified date on that but I also have to remember to trace up the > >> > tree to its parent objects and flag them as modified, does that make > >> > sense? and likewise if objects are added or removed from deep level > >> > collections the parents have to be set as modified. > > >> > This approach works o.k. for me right now, its just a little > >> > unregulated and I occasionally find anomalies where particular objects > >> > are modified and yet the client is not aware of the change so doesn't > >> > pull the package down again because I've missed something somewhere. I > >> > was just looking for something a little more failsafe. If you have a > >> > nice implementation for updating the modified dates cleanly with some > >> > type of observer system or something then I'd be a lot more keen on > >> > that anything that takes the responsibility off me to consider all > >> > possible modifications which could happen to an object. > > >> > Another small niggle in my mind that I can see the checksum type > >> > solution solving or indeed would like to solve in another way is that > >> > if one of my users opens up an object and clicks 'save' without > >> > actually making any changes then it would be good that the system is > >> > aware that a proper 'change' to the content wasn't actually made and > >> > wouldn't need to suck the content down. > > >> > I get your idea on only pulling the objects which have been modified > >> > I'm just not sure that the object tree I have makes it all that > >> > simple, for instance, say one of my objects has one of its children > >> > deleted and I need to reflect that on my client, without getting into > >> > complex service calls to depict that deletion the only way it to pull > >> > down the entire collection, less the deleted object and re-save the > >> > collection as its intended to be used, is that right? or can you think > >> > of something better to tackle that problem? > > >> > Whatever I can do to minimize bandwidth suits me down the ground so > >> > I'm all ears :-) > > >> > Thanks Brian, > > >> > Rob > > >> > On Mar 6, 8:14 pm, Brian Kotek <[email protected]> wrote: > >> >> It sounds like it might work, but I'd check to confirm that the > >> >> checksums > >> >> match. Keep in mind that if anything happens that changes the checksum > >> >> of > >> >> the object (I don't know, if Mark changes something about the generated > >> >> memento or something) it's going to cause everything to show as > >> >> changed. > > >> >> I have to ask though, why can't you just check a "lastModifiedDate" and > >> >> only > >> >> return records that were modified since the last call (which I assume > >> >> they're passing or you record somewhere)? > > >> >> On Fri, Mar 6, 2009 at 11:48 AM, Sir Rawlins < > > >> >> [email protected]> wrote: > > >> >> > Hello Chaps, > > >> >> > I've got a scenario here where I provide a collection of objects over > >> >> > a webservice. Now the objects can be substantial in size due to the > >> >> > binary data that they contain (several Mb sometimes) so my use case > >> >> > defines that I should only supply the object over the webservice if > >> >> > its content has been altered since it was last collected by the > >> >> > client, this is due to the high frequency of calls from the client > >> >> > and > >> >> > wanting to minimize overhead and bandwidth. > > >> >> > At the moment I have a rather messy solution where I keep a boolean > >> >> > column on the tables which gets updated to true if the content has > >> >> > been modified, however this becomes complicated as the composition of > >> >> > objects grows and I have to remember to flag objects parents as > >> >> > modified when their children are modified, with an ever growing > >> >> > object > >> >> > tree this is breaking my balls. > > >> >> > To be frank I'm kind of getting bored of it and at the moment I'm > >> >> > thinking a simpler and less code intensive method to solve the issue > >> >> > is the serialization of the objects and creating a checksum for the > >> >> > collection. > > >> >> > This way when the client requests the collection from the webservice > >> >> > it gets the data handed to it along with an MD5 hash for the > >> >> > collection. Then, when next making a call the client gives that MD5 > >> >> > hash to the server in its request, the package is built on the server > >> >> > and hashed, if the two hashes match then the package content has not > >> >> > changed and nothing needs to be sent back to the client, however, if > >> >> > the hashes do differ then the package content can be returned over > >> >> > the > >> >> > service. > > >> >> > Now, My initial thoughts on this were to simply create a string out > >> >> > of > >> >> > the getPropertyMomento() struct and then hash it, however I don't > >> >> > think this will work when we have collections of composed objects > >> >> > within one another. > > >> >> > Do you think this approach is a good way to tackle the challenge? if > >> >> > so then how would you go about the serialization of the object? It > >> >> > doesn't appear that CF has any native features built into its objects > >> >> > to support this, have we got any sexy hacks using metadata or > >> >> > something? > > >> >> > Many thanks guys, appreciate your opinions as always. > > >> >> > Rob > > >> -- > >> E: [email protected] > >> W:www.compoundtheory.com > > -- > E: [email protected] > W:www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
