Pykesto is currently being written in Python 2.6. It shall be a schemaless, transactional, concurrent, queryable (indexable), object-oriented database for Python applications.

Pykesto should provide the easiest way to write persistent Python objects. Pykesto should become to Python what db4o is for Java and .net: a very competent persistence mechanism that speaks the language it was developed in.

What about SQLAlchemy, ZODB, Durus, CouchDB or MongoDB? See WhyNotTheAlternatives.

Pykesto Layers

1. The TokyoCabinet backend

Status: beta

TokyoCabinet is being tried out for the storage backend. See the blog. A Python driver, wrapping the Tokyo Cabinet table database, is almost finished. (TC offers several persistence flavours (none of which relational) and we are probably using the "table" one).

Our driver, written in Cython, behaves like a Python dict where everything is a bytes instance. It can already be queried: query = t.query.col('age').equals('180')

This driver can be reused in other projects, not just Pykesto.

2. Transactional layer

Status: planning

We shall have a transactional layer similar to SQLAlchemy's: session.commit(), session.rollback().

Concurrency control

When several users access the same database at the same time and are allowed to update records (which is the case in a web application), conflicts can occur if two users want to update the same row.

We are planning to use a version number to detect the conflicts. Each row shall have a version number (an integer). When the row is read, the version number will be provided as an attribute k_version; when commit() is called, the program shall first look at the version number of the row with the same identifier in the database. If the version number has changed, this is because another user has updated the record in the meantime. In this case, an exception (ConcurrencyConflict) will be raised. It shall be up to the programmer to decide how to manage the conflict.

We are thinking of providing a commit(force=True) option that won't look up versions.

This manner of managing concurrency has the advantage that locking is only needed on commit.

3. Optional client/server layer

Status: planning

This is an embedded database, but a server can be written to allow many clients to use a single database over the network.

4. Schemaless layer

Status: alpha

Because the backend works with bytes instances (for row IDs, columns and values), we shall have a layer responsible for serializing and deserializing Python values -- without using Pickle, because it is too verbose.

Please join the project.

We need more developers. One way to reach me is through IRC, on #webpyte at Freenode.