Re: RFC: Data::Sync

[dragonchild]

A few notes:

• Your distribution doesn't provide a MANIFEST, META.yml, or Build.PL. Since Module::Build will create a standalone Makefile.PL for you using the create_makefile_pl => 'traditional' option, there's no reason not to use it.
• If someone set RaiseError on their $dbh, you will throw all those errors. Wouldn't it make more sense to wrap everything in a eval-$@ block?
• You cannot depend on the return value of $sth->execute(). According to the DBI documentation, The execute method does not return the number of rows that will be returned by the query (because most databases can't tell in advance), it simply returns a true value. You explictly check for '0E0' where you should be checking for simple truth.
• You make the same mistake re: return value of execute() in your write function.
• The cost of doing a UPDATE then an INSERT can become prohibitive. You should look at DBD-specific options, such as REPLACE for MySQL.
• Every RDBMS in existence has a way of doing bulk-pulls and bulk-loads from some xSV file. It might be worth your while to exploit that if you know your source and destination are both RDBMSes. My experience has been that bulk-loads perform over 100x faster than DBI queries. You can always use File::Temp for temporary filehandles.
• Your code currently just makes sure that everything in A is in B. You don't validate the other way around. This may be by design, but "synchronization", to me, means that A and B will provide the same information. Something akin to MySQL's replication would be more synchronization, to me.
• A design note - I would have gone about it a different way:
  1. Define an API that every class wrapping a datastore must adhere to. write(), read(), temporary files, etc.
  2. Provide a class that implements that API for every type of datastore supported. For example, LDAP, DBI::generic, DBI::mysql, etc.
  This would simplify testing and implementation. Plus, others can provide optimized implementations for their favorite datastore and you don't have to change the controller. In fact, I could write one for my specific needs and not have to give it back to the community (if, for instance, my employer is an @$$hole who doesn't believe in contributing to OSS but doesn't mind using it). Currently, you have to modify the main module, which is fraught with danger.