Wednesday, February 3, 2010

CouchDB Lucene: A Tail of Woe

‹prev | My Chain | next›

Way back when, I got couchdb-lucene 0.2 installed and running with CouchDB 0.9. Now that I am upgrading to a later version of CouchDB, I might as well bump up my couchdb-lucene version as well. This will also afford me the opportunity of dumping my couchdb-lucene fork in favor of the original. The maintainer, the esteemed Robert Newson, is recommending the soon-to-be released version 0.5 (currently on the master branch in github).

First up install maven. On a (relatively) fresh Ubuntu install, this begins with:
cstrom@whitefall:~/repos/eee-code$ sudo apt-get install maven2 sun-java6-jdk
After 20 minutes (depending on your internet connection) of waiting for apt-get to download and install maven2 and dependencies, I am ready to begin:
cstrom@cstrom-laptop:~/repos$ git clone git://github.com/rnewson/couchdb-lucene.git
Initialized empty Git repository in /home/cstrom/repos/couchdb-lucene/.git/
...
cstrom@cstrom-laptop:~/repos$ cd couchdb-lucene/
cstrom@cstrom-laptop:~/repos/couchdb-lucene$ ls
couchdb-external-hook.py LICENSE pom.xml README.md src THANKS.md TODO
Cool beans. I am ready to go. A simple mvn ought to do it:
cstrom@cstrom-laptop:~/repos/couchdb-lucene$ mvn
...
Results :

Failed tests:
dateRangeQuery(com.github.rnewson.couchdb.lucene.CustomQueryParserTest)
dateTimeRangeQuery(com.github.rnewson.couchdb.lucene.CustomQueryParserTest)

Tests run: 37, Failures: 2, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Gah! I have no idea what the problem is nor do I feel like fiddling with maven or tests. Github is down, so any possible issues are not readable tonight. This may not be my night.

Next up, I give version 0.4 a try. 0.5 is new / still experimental, so maybe 0.4 will work:
cstrom@cstrom-laptop:~/repos/couchdb-lucene$ git tag
pre-v0.3
v0.1
v0.2
v0.3
v0.4
cstrom@cstrom-laptop:~/repos/couchdb-lucene$ git checkout v0.4
Note: moving to 'v0.4' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 886a12b... v0.4 release.
cstrom@cstrom-laptop:~/repos/couchdb-lucene$ mvn
...
Results :

Tests in error:
longIndex(com.github.rnewson.couchdb.lucene.IntegrationTest)
index(com.github.rnewson.couchdb.lucene.IntegrationTest)

Tests run: 27, Failures: 0, Errors: 2, Skipped: 1

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Aw, fer cryin' out loud!

Lacking any better plan, I switch back to the master branch and check out the actual failure messages:
java.lang.AssertionError:
Expected: is <946684800000L>
got: <946702800000L>

at org.junit.Assert.assertThat(Assert.java:750)
at org.junit.Assert.assertThat(Assert.java:709)
at com.github.rnewson.couchdb.lucene.CustomQueryParserTest.assertRange(CustomQueryParserTest.java:75)
at com.github.rnewson.couchdb.lucene.CustomQueryParserTest.dateRangeQuery(CustomQueryParserTest.java:49)
...
If I had to guess, that looks like GMT/timezone offset difference. But I'm only guessing at this point. If nothing else, I'd at least like to get this built, so I disable the two failing tests by commenting out the @Test jUnit directive:
...
//@Test
public void dateRangeQuery() throws Exception {
final Query q = parser.parse("blah<date>:[2000-01-01 TO 2010-02-04]");
assertRange(q, Long.class, 946684800000L, 1265241600000L);
}

//@Test
public void dateTimeRangeQuery() throws Exception {
final Query q = parser.parse("blah<date>:[2000-01-01T00:00:01 TO 2010-02-04T00:00:01]");
assertRange(q, Long.class, 946684801000L, 1265241601000L);
}
...
That finally gets me a JAR. I will stop there tonight. Tomorrow I will either try to troubleshoot this or try to get the new JAR working with my old code. Depends on how much Java I think I can take at that point.

Update: Robert fixed the problem with master the next morning.

Day #3

No comments:

Post a Comment