<br><div class="gmail_extra"><div class="gmail_quote">On 12 December 2012 01:53, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,</blockquote><div><br><snip><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It would be great if someone were to add support to Osmosis which is likely to be a bit tricky as you have to shove replication information through the pipeline, but if all else fails I might have a go at it during the holidays.</blockquote>
<div><br>I've done something similar with the streaming replication tasks  (ie. --receive-replication, --replicate-apidb, --send-replication-data, --write-replication).  They exchange state information from source to sink via the new task "initialize" method which accepts a map of arguments.  Typically the source task at the start of the pipeline passes a ReplicationState object through the pipeline in a map key called "replication.state" (I think ... I'm not looking at the source code).  The sink task then updates the state object with the current persisted state during the initialize call, and by the time the initialize call returns, the source task can use it to determine what replication point to start from.<br>
<br>As part of that change I updated tasks such as --buffer to propagate the initialize information properly across threads.  I believe other tasks such as --merge will still need to be updated.<br><br>I doubt if I'll be able to provide much assistance in implementing this.  I have another child due early in the New Year so I'll probably be off the radar for a while :-)<br>
<br></div></div></div>