Thanks Brian, forgot my * own * API there. Brian is right - check out: http://docs.transfer-orm.com/html/transferapi/transfer/com/Transfer.html#visitObjectGraph()
(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 -~----------~----~----~----~------~----~------~--~---
