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
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to