elasticsearch/elasticsearch-river-couchdb — pull request #27 by pawelrychlik (2013-04-23 19:26:56+00:00)
Title: Retrying failed index requests + lots of refactoring

What's this all about?
======================

What I wanted to achieve with this fork in general is a reliable, maintainable & easy-to-extend piece of software.

Improvements of reliability:
----------------------------
+ conditional retrying of failed index requests
+ initial index creation with 10 attempts

Improvements of maintainability:
--------------------------------
+ the code has been *heavily* refactored leading to an object-oriented design, alignment to SOLID principles & Uncle Bob's Clean Code :)
+ better readability and comprehensibility
+ main class was split into a handful of fairly small, decoupled individual components, each of single responsibility and potentially reusable or swappable.
+ a pack of BDD-like unit-tests covering essential behaviors
+ integration test covering listening to real CouchDB's changes feed
+ unit & integration tests guard against future regression

Improvements of extensibility:
------------------------------
The code is pretty much prepared to be a skeleton for other applications. You could easily (still - usually programatically) customize it to suit your needs. You might need to index multiple CouchDb databases into a single elasticsearch index. Or maybe the other way around. Or perform some complicated transformations on the fly. Or use some external resources to decide how to index things. Obviously there is no almighty software, still I believe that it's going to be easy enough to customize/extend this version of river.
What's out there:
+ onIndex & onDelete hooks out-of-the-box
+ custom indexing-retrying strategies are one step ahead
+ multiple slurpers & indexers can be easily set up with existing bits of code.

Summary
-------
The only functional changes are those listed in reliability improvements section. All the rest is about refactoring, and making this plugin more developer-friendly. Plus, I decided to draw the lines a little different in configuration JSON, so it would be easier to add more slurpers/indexers.

I hope that it would be significantly easier for other developers to grasp the overall concept and to customize their river on top of this patch. What do you think, guys?