With the GPL’ing of Java and Lucene’s pending move to using Java 1.5,
I decided to give PyLucene without gcj a try.

One of the best features of gcj is its C++ interface. Its ability to expose Java classes as C++ makes it very easy to invoke Java from C++. This feature is unique and sorely missed when moving off of gcj.

The Java Native Invocation Interface makes it possible to invoke Java
classes from C++ but is rather crufty and verbose to use by hand.

I started by implementing a C++ code generator that generates C++ wrapper
classes that hide all the JNI invocation cruft from the C++ programmer.
These wrapper classes in effect offer a very similar C++ interface to what
is offered by gcj’s CNI.

While I was implementing this it became apparent that the C++ wrappers for
giving access to Java classes from Python could be generated at the same
time.

Eventually, I ended up writing a new C++ code generator, that I called jcc.
JCC is able to generate C++ wrappers for accessing Java classes from Python
and C++.

This code generator is now used to generate a new flavor of PyLucene, called
PyLucene with JCC. JCC has no built-in knowledge about Lucene and could be
used to generate wrappers for any Java library that uses similar coding
styles and techniques than the ones used by the Java Lucene developers.

JCC could in fact become a project of its own. At the moment, it is part of the
PyLucene with JCC source tree.

The PyLucene source tree got split into two forks, a gcj fork containing the
original PyLucene and a new jcc fork containing the new sources, consisting
mainly of unit tests, samples and the sources to jcc since all of
PyLucene, except for extension code, is now generated by jcc.

For more details, please refer to the new README files:

• PyLucene README
• PyLucene with JCC README
• jcc README

To support the requirements of Chandler, the repository had to implement a richer set of notifications than what was originally offered with attribute monitors.

Read the rest of this entry »

A collection item is an item that wraps an abstract set of items or bi-directional item references.

Read the rest of this entry »

Java Lucene 1.9 was finally released this Monday. PyLucene 1.9 is now available.

During last week’s sprints I was asked to see how easy it was to import mail into Chandler from a local mailbox. Thanks to Python’s mailbox and email packages, the mailbox parsing was trivial. Similarly, Chandler’s domain model can represent email items and has a number of APIs that make creating such items from a raw email string very easy.

Read the rest of this entry »

It’s been a while since I posted anything on the chandlerdb blog. That is now corrected with a few new posts about repository backup, recent performance improvements and version purging.

Chandler’s repository is versioned. Like a subversion source code repository, changes to items are saved into the repository as coherent versions. This enables to later merge together changes that occurred in different threads or processes instead of serializing changes by locking resources.

Read the rest of this entry »

In the run up to the Chandler 0.6 release, a lot of performance improvements were made to the repository codebase. Many areas of Chandler were also reworked somewhat to make better use of performance critical repository features.

Read the rest of this entry »

Chandler’s repository is intended to store a lot of data that one cannot afford to lose. It should come as no surprise that doing regular backups is strongly recommended. There are a few repository APIs, currently accessible from Chandler’s “Test” menu or from Chandler’s --restore command line option, that make it possible to backup and later restore a repository’s files.

Read the rest of this entry »

PyLucene is a GCJ-compiled version of Java Lucene integrated with Python via SWIG. Its goal is to allow you to use Lucene’s text indexing and searching capabilities from Python. It is designed to be API compatible with the latest version of Java Lucene.
PyLucene 1.0 is available from its homepage.