On Jul 20, 2012, at 10:02 AM, Alexey Klyukin wrote: > Hello, > > I've been reading the source code of Bucardo 4.8 recently (to deepen my > understanding of how it works) and came across the following comment in a > section that deals with the swap sync: > > ## Go through all keys and resolve any conflicts. Bitmap action: > ## 1 = Add source row to the target db > ## 2 = Add target row to the source db > ## 4 = Add source row to the source db > ## 8 = Add target row to the target db > > Later, throughout the code, there is full support for actions 4 and 8, > although one can only trigger them from the custom conflict handler, as > standard ones only produce 1 and 2. Per my understanding, these actions are > mostly no-op, for delete they delete non-existant rows from the source or > target databases (cause they were already deleted), for non-deletes they just > update the rows on source/target with exactly the same values, increasing the > table's bloat. Also, if the sync is set to 'makedelta', then these actions > would also duplicate rows in the corresponding delta tables, but with the > more recent timestamps. > > Since the row is not replicated to another DB I'm wondering if these are > 'skip' actions, i.e. those to not replicate the conflicting row. > > Is there a real-world example that makes replication useful for 'source to > source' and 'target to target' actions?
My attempt to answer my own question. I haven't paid enough attention to the fact that conflict actions are bitmapped, i.e. one can update source row to the source db and update the same source row to the target db in the same sync. Now, given the fact that a conflict handler can receive the reference to the delta rows (when customcode.getrows is true for the relevant record in the bucardo.customcode table), and can modify, the action that propagates the row to the same database it supposedly originated from opens the door to more sophisticated customcode handlers, i.e. those that instead of electing either source or target row as a winner, modify the row inside the conflict handler and propagate the modification to both databases (one of them would be the origin of the original row) via a combination of actions. Let me know if my guess is right :-) > > BTW, there seem to be no support for the truncate for swap replication (i.e. > truncate will do nothing), although the swap sync will be kicked by the on > truncate trigger. Am I understanding this correctly? > > Thank you, > Alexey. > _______________________________________________ > Bucardo-general mailing list > [email protected] > https://mail.endcrypt.com/mailman/listinfo/bucardo-general Thank you, /A _______________________________________________ Bucardo-general mailing list [email protected] https://mail.endcrypt.com/mailman/listinfo/bucardo-general
