easy_install -U XRecordor
pip install XRecord
XRecord is an Object-Relational Mapper - 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:
XRecord is not meant to replace any of them, but rather - provide an alternative approach to Object-Relation mapping. XRecord also attempts to be a thin Database Abstraction Layer - not as thin as MysqlDB, pg or sqlite3 modules, but a as thin as possible to make using an RDBMS quick and easy without hiding any of its powerful features.
The XRecord package contains a small web application which allows you to view the structure of your database with all the table relationships.
Read more about it here, or check out the live demo.
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 we found that they all share some design decisions, as result of which they don't exactly fit our 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, we believe this to be in a little conflict with the DRY principle, of which we are big fans. 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 we often choose our RDBMS back-end based on one of its distinctive features, which will make my work faster, so we 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, and sometimes it may be even uglier and less maintainable than the low-level API.