insertUpdate() Logic: Server updates are overridden.

[Kumar]

Hi,

I just wanted to check the logic behind the insertUpdate() method...
looks like currently all the server changes are overridden by the
client changes.

My understanding is that sendXhrPost() method gets all the lastest
data from the server and passes the latest notes to the insertUpdate
(notes).

In the insertUpdate following things are done:

a) REPLACE the server notes updates into the CACHED_NOTES table.
b) DELETE the cached notes outside the boundary. (EVICT_)
c) UPDATE write_buffer status= STATUS AND 8.

that would invoke the "replaytrigger"

d) REPLACES the CACHED_NOTES with the records from the BUFFER.

So here step (d) replaces all the server updates to the cache in step
(a). I am assuming that in step (a) we need to update the BUFFER
instead of the CACHED_NOTES to preserve the server updates.

Any suggestions ?

Thank YOu.
Kumar

[Rob]

On Jul 5, 11:50 pm, Kumar <kumaravel.kandas...@gmail.com> wrote:
> Hi,
>
> I just wanted to check the logic behind the insertUpdate() method...
> looks like currently all the server changes are overridden by the
> client changes.

This is essentially so.

>
> My understanding is that sendXhrPost() method gets all the lastest
> data from the server and passes the latest notes to the insertUpdate
> (notes).
>
> In the insertUpdate following things are done:
>
> a) REPLACE the server notes updates into the CACHED_NOTES table.
> b) DELETE the cached notes outside the boundary. (EVICT_)
> c) UPDATE write_buffer status= STATUS AND 8.
>
> that would invoke the "replaytrigger"
>
> d) REPLACES the CACHED_NOTES with the records from the BUFFER.
>
> So here step (d) replaces all the server updates to the cache in step
> (a). I am assuming that in step (a) we need to update the BUFFER
> instead of the CACHED_NOTES to preserve the server updates.
>
> Any suggestions ?

I deliberately simplified the simplenotes coherency policy to a point
where I could get it written in half a day. :-) That being said, I
think that the implemented behaviour is preferable to the user: the
changes just made on the device in use should take precedence over
remote and the server can sort out conflicting changes.

I think that a fully productionized version of simplenotes would need
to be less naive. In particular, when/if I rewrite simplenotes as a
product instead of a simplified demo, I might have modifications
expressed as an edit delta and each note having both a version as well
as an id. The cache would then contain the latest version known to the
local device and the write buffer would contain the aggregated deltas
since the note was last updated from the server. The server in this
context would operate somewhat like an SCM and merge the changes (the
RCS algorithm perhaps) from clients to produce the definitive master
version. Refreshes in the absence of conflict would get written into
the cache on refresh.

Rob.

>
> Thank YOu.
> Kumar