The Chandler Project Blog

Sleepycat’s Berkeley DB software, which provides the persistence underpinnings to Chandler’s repository, can be configured to use the AES (Rijndael) algorithm to encrypt its data files.

(more…)

While an item’s UUID is normally used to compare items for sameness, there are times when it is useful to compare item instances with different UUIDs as, for example, while importing items from another repository. The Item class does not implement any Python comparison hook functions, comparing items is left to the implementors since meaningful item comparison depends on the items’ schema and on the knowledge of the implementor. For instance, not all attributes are equally relevant, some may even be completely irrelevant for comparison purposes. To help with this, a new API, hashItem(), was added to the Item class. Two items can be defined to be the ’same’ when their hash values are the same.

(more…)

Now that items can be created in a null repository view, how about persisting them ?
By definition, a null repository view, is not capable of persisting items. In the context of Phillip Eby’s Schema API proposal, items are persisted in python code and instantiated into the null repository view upon python’s loading of the module.

(more…)

In order to support Phillip Eby’s proposal for a python-based Schema API, I added support for a repository-less repository view.

(more…)

The focus of the repository work for Chandler’s 0.5 release was mostly about startup and commit performance. The approach taken was to run these operations in the hotshot profiler to find out more about the slow areas and rework them. This macro-performance effort can yield useful results. For instance, commit was made twice as fast by rewriting it to not use any XML.
For 0.6, I’d like to also look at performance at the micro-level.

(more…)

One focus of development in the repository project for the Chandler 0.5 release has been performance. After removing dbxml from the persistence implementation stack, I continued by removing the use of XML for persistence altogether.
(more…)

As with item copying Item clouds can now be used to define a set of items to delete together.

(more…)

An attribute monitor is a method defined on an item that is invoked when something happens to the attribute(s) it registered an interest in. That invocation is synchronous and reacts to changes on items in the same repository view as the item of the method being invoked.

(more…)

A year and a half ago, when the Chandler repository project was (re-)started, I chose to use Sleepycat’s Berkeley DB and DBXML for the persistence layer.
(more…)

The transaction model chosen for Chandler’s repository calls for item version merging. In the Chandler 0.4 release, version merging is mostly implemented, with a few notable exceptions.

(more…)