[Bucardo-general] customecode attempts: missing 'rows' content and other fun

Meg Green mawg at lanl.gov
Thu Mar 5 19:03:57 UTC 2009


Hello,

Longtime listener, first time caller.

Thanks for any thoughts or suggestions.
Regards,
Meg


-----------------------------------
Here is the basic curiousity right now:

Using customecode set on the sync, exec'ing before the sync, the  
passed hash does not contain the rows to be changed.  There is likely  
something I am missing in the content here, but the 'rows' hashref is  
empty.

The customecode is set  to getrows:

bucardo=# select * from bucardo.customcode;
  id |      name      |                           
about                           |   whenrun   | getdbh | getrows  
|                                                                        
                                                           
src_code                                                                 
                                                                   
|             cdate
----+---------------- 
+---------------------------------------------------------- 
+-------------+--------+--------- 
+----------------------------------------------------------------------- 
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
-------------------------------------------------- 
+-------------------------------
   2 | test_setlookup | test script eventually to deal with  
set_lookup conflicts | before_sync | t      | t       | my ($result)  
=@_; open F, '>/tmp/test_setlookup_out'; print F $result->{syncname};  
use Data::Dumper; print F Dumper $result; close F; $result->{message}  
= 'BOB WUZ HERE'; $result->{warning} = 'TRYING TO USE BOB TO WARN';  
return $result; return if $result->{dummy} | 2009-03-04  
12:55:59.428957-07
(1 row)

my dump file (/tmp/test_setlookup_out) from this config is attached.   
Here is a snippet:

<outfile snippet>
$BUCARDO1 = {
   'sourcename' => 'asiatic',
   'sourcedbh' => bless( {}, 'DBIx::Safe' ),
   'runagain' => 0,
   'syncname' => 'isd_sync',
   'rows' => {},
   'message' => '',
   'targetname' => '',
   'synctype' => 'swap',
   'error' => '',
   'warning' => '',
   'endsync' => '',
   'goatlist' => [
     {
       'schemaname' => 'public',
       'db' => 'asiatic',
       'does_makedelta' => '0',
       'cols' => [
         'num_code',
         'name',
</outfile snippet>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_setlookup_out
Type: application/octet-stream
Size: 84727 bytes
Desc: not available
Url : https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20090305/3b6d543f/attachment.obj 
-------------- next part --------------



Ideally I would like to only fire the customecode when the specific  
table has deltas, but attempting to set the customecode to the  
goat.id of the table never fired the code.  I'll be breaking that  
table from the main sync next and working with it alone to see if I  
can get better results (but for deployment it seems best to not add  
the complexity of multiple syncs for the same project/dbs)



-----------------------------------
Here is more detail on our scenario:

We have a "search results" table that has many inserts and deletes,  
and some rows that are untouched over very long periods of time  
(something like "saved searches").

It appears we are generating many, many exceptions because of this  
table, and we are considering how best to deal with it.

Solution One:  use customecode and basically ignore attempts to add  
duplicate rows.

Solution Two:  use customecode to NOT replicate the "search  
results" (the saved searches do need to be replicated)


  
  


More information about the Bucardo-general mailing list