My initial plans got waylaid! I didn’t pull out the checksumming code first, because the code wasn’t at all as I remembered it. Instead, I began writing code to handle the more abstract problem of accepting two sets of rows, finding the differences, and doing something with them. I’m ending up with a little more complicated system than I thought I would. However, it’s also significantly simpler in some ways. Instead of just passing references to subroutines to use as callbacks, I’m object-ifying the entire synchronization concept.
What’s the advantage of doing this? Well, as some of you may know, there are two fairly complex algorithms in the tool at present, which handle synchronization in a hierarchical manner, zooming in on the rows that need to be changed. There are a lot of complexities in them. If I wrap all that up into modules, and make them have a uniform interface (real OO interfaces would be delightful here, but Perl doesn’t support them), I can simplify the project significantly by…
…throwing them out the window! That’s right, I’m tossing out the ‘top-down’ and ‘bottom-up’ algorithms. What I want to develop, first and foremost, is the code that does the synchronization, not the really twisted code that does bitwise XORs on groupwise slices of checksums and has recursion and all that stuff. So I decided on a generic data-syncing interface, and wrote the simplest possible implementation of that, which I’m going to use to help me deal with complexity. This algorithm is called ’stream’ (for lack of a better word). It has no hierarchical drill-down or any other complexities. It amounts to “select * from source, select * from dest, diff and resolve.”
It’s not a very efficient algorithm for comparing and syncing data, at least not by my standards. (It amounts to a FULL OUTER JOIN implemented in Perl). But boy, does it make it easier to start cleaning up the nasty spaghetti code that handles locking, waiting for a slave to catch up, actually changing the data that turns out to be different, and so on.
Of course, I’ll add back the top-down and bottom-up algorithms later, as well as some others. They should turn out to be pretty simple to implement, since they won’t have, for example, locking code intertwined with them. When done, the tool will examine the table and figure out the best algorithm to use. This will go a good way towards another of my goals, which is that you should be able to just point it at two tables and tell it to sync them, and it should do it in the most efficient way possible, without needing lots of command-line options.
Technorati Tags:mysql, OOP, sql, synchronization
Why is Embarq hijacking my DNS?
Isn’t this the same thing that happened a few years ago with ICANN or Verisign or one of those big names? (strangely, I can’t find relevant search results about this!).
I clicked on my toolbar shortcut for Toggl and my Embarq DSL service redirected me to a search-results page instead of telling my browser the truth. This makes me mad. The core layers of the Internet are designed the way they are for a reason and I don’t want to “opt out” of a stupid DNS hijacking stunt I never opted into.
Here’s a screenshot of what happens when I type in any old non-existent (or, in Toggl’s case, timing-out) domain name.
And here’s what happens when I do a DNS lookup:
Did I mention that this makes me mad? Time to get on the phone.
PS: it looks like Verizon is doing it too.
Technorati Tags:DNS, Embarq, opt out, Toggl, VerizonNo related posts.