XRecord 0.1.6

An Introspecting Python ORM

  Add it to your Download Basket!

 Add it to your Watch List!


Rate it!
send us
an update
BSD License 
5.0/5 1
Jakub Wroniecki
ROOT \ Database \ Database APIs
XRecord is a library which provides an object interface to databases. Tables are represented as classes, columns are attributes, and rows of data are class instances. If you used Python for developing database applications you may have come across one or more of ORMs, like:

 * SQLObject
 * SQLAlchemy
 * Autumn
 * Storm
 * many more...

XRecord is not meant to replace any of them, but rather - provide an alternative approach to Object-Relation mapping. XRecord also tries to be a thin Database Abstraction Layer - make using an RDBMS quick and easy without hiding any of its powerful features.

Why another ORM?

It's seems that the "Python ORM market" is filled with some excellent solutions, all of which do what is expected of them really well. However, while using most of them I found that they all share some design decisions, as result of which they don't exactly fit my needs.

Most of existing Python ORMs require you to actually write the classes onto which rows of data will be mapped. They require you to explicitly define the foreign keys in your classes (tables) and to describe the many-to-many relationships. Since all of this information is already inside your RDBMS, I believe this to be in a little conflict with the DRY principle, of which I am a big fan. Some ORMs try to counter this problem by leaving the database (model) definition entirely in Python code, but this is just a superficial solution - even though your model is defined in Python, your data is still stored in an external database and their structures do not always have to be in sync.

Most existing Python ORMs are designed to hide all SQL from the programmer, but still allow complex queries to be performed through an abstraction layer put on top of low-level database API. This makes the code look clean, and RDBMS independent. It is common for applications to be developed and tested with SQLite, and then switched to MySQL/PostgreSQL in production, which is both elegant and convenient.

However, this approach has some issues. All of the widely used RDBMS, are highly sophisticated, mature projects, with thousands of man-hours put into development, testing and optimization. Most of them introduce many handy improvements to the SQL standard (non standard types, alternative syntax, etc), which may be lost when using a unified abstraction layer (which, btw, may be a source of new bugs).

So the price for the clean code, and platform independence, may be reduced functionality of your database system. When writing quick, small applications I often choose my RDBMS back-end based on one of its distinctive features, which will make my work faster, so I looked for an ORM which made using it easier, rather than more difficult.

Some may argue, that all of the aforementioned ORMs have built-in hacks (or even features :) ) to overcome all these problems. That's true, but it's just not the way they were designed to be used - so by using these hacks, you no longer have clean, engine-independent code, but sometimes it's even uglier and less maintainable than the low-level API.

Common ORM features that were left out

 * no object caching, no Store
 * no way to customize SELECT queries without writing SQL
 * no automatic database generation

Supported RDBMS

 * MySQL
 * SQLite
 * PostgeSQL (work-in-progress)

Last updated on December 25th, 2009

feature list requirements

#Python ORM #object interface #Python library #Python #ORM #object #interface

Add your review!