rhec/pyelasticsearch — pull request #24 by erikrose (2012-09-08 07:20:00+00:00)
Title: Votizen

I've embarked on a fairly aggressive rethink/rewrite to gain the elements needed by Votizen and Mozilla for production use. What do you think?

* Add load-balancing across multiple nodes.
* Add failover in the case where a node doesn't respond.
* Add `close_index`, `open_index`, `update_settings`, `health`.
* Automatically convert `datetime` objects when encoding JSON.
* Rethink error handling:
* Raise a more specific exception for HTTP error codes so callers can catch
it without examining a string.
* Catch non-JSON responses properly, and raise the more specific
`NonJsonResponseError` instead of the generic `ElasticSearchError`.
* Remove mentions of nonexistent exception types that would cause crashes
in their `except` clauses.
* Crash harder if JSON encoding happens: that always indicates a bug in
pyelasticsearch.
* Remove the ill-defined `ElasticSearchError`.
* Raise `ConnectionError` rather than `ElasticSearchError` if we can't
connect to a node (and we're out of auto-retries).
* Raise `ValueError` rather than `ElasticSearchError` if no documents are
passed to `bulk_index`.
* In routines that can take either one or many indexes, don't require the
caller to wrap a single index name in a list.
* Rename `morelikethis` to `more_like_this` for consistency with other
methods.
* Many other internal improvements

Still planned:

* Kill off `quiet` kwarg where it doesn't make sense.
* Review each API, and make sure the calling conventions are standardized so callers don't have to refer to docs much. Also, I have a design worked out that should allow bleeding-edge people to pass arbitrary querystring args through to ES (as it introduces them at a breakneck pace) without wrecking our ability to add kwargs to make the APIs feel natural. Proof of concept to come.
* Fewer lines of code. Still feels like too many for what it does.

I can't seem to stop hacking on this. :-)