No Mind

It's the mind that makes you miss the shot
January 21st, 2009

Playing with dejavu

So spend last night messing around with dejavu orm. While I was chatting with dejavu team over IRC and pointing bugs, fumanchu was busy fixing them asap. We had 3 revisions of dejavu in one hour and one new ticket.  It turned out that geniusql can not handle NULL in mysql timestamp type. Mysql’s timestamp is a badly designed data type, from the manual, “TIMESTAMP columns are NOT NULL by default, cannot contain NULL values, and assigning NULL assigns the current timestamp. However, a TIMESTAMP column can be allowed to contain NULL by declaring it with the NULL attribute”.  Now that’s a horrible way to design a datatype. To support both NULL and NOT NULL, some modifications are required in the geniusql and a ticket has been filed for the same.

So dejavu 2.0 is becoming stable day by day… Enjoy…

December 15th, 2008


Recently I started playing with dejavu ORM by Robert Brewer. For first time I found a python ORM which can be a  replacement for my over used data layer. Dejavu allows you to interface with more than one data source and this is a blessing when you are building application that have to fetch data from legacy or proprietary database along with  SQL based database(s).

Dejavu has done lot of things correctly in the design itself. Dejavu uses data mapper architecture, which creates loose coupling between the database and in-memory objects. This separation is achieved with help of a data mapper for translating in-memory objects to database tables. As in-memory objects do not have any responsibility of database operations, the domain layer can focus on one thing that it is meant for ‘domain logic’. As in-memory objects talk to database through a data mapper, they can talk to more than one data mapper and connect to multiple data source, plus the data source need not be a database. It can be anything for which a data mapper exists, thus allowing you to build business objects which can be composed of multiple data sources.

Normally organizations have multiple data sources and applications have to either replicate data or create multiple access layers to accommodate every data source. In such scenarios the loose coupling in dejavu is nothing short of a blessing. With an ORM capable of connecting to multiple data sources, you can expect reduction in development time and number of bugs.

Second good feature of dejavu are the triggers, behaviours that fire when value is changed. It is not uncommon for developers to write logic in the code which is fired on value change, for example update the value of A by 10 if the value of B is more than 20. We do this by writing tons of if-else statements, which becomes  hard to maintain as the code size grows. With dejavu, you can delegate the responsibility to ORM, resulting in easy to maintain code.

I also liked the way dejavu has separated the deployment from development. The official guide comes with a neat example of the config file to explain the deployment. No more complicated XML syntax when all I want to specify is  the database driver and connection string…

I can continue praising dejavu but I think I have done enough.. I think its time now to search the shortcomings of dejavu as by now I am not been able to find any. I am going to play with dejavu more and post about shortcomings as I come across, along with few examples of how to use dejavu…