Refactorings

On a recent Symfony 1.0 project I’ve been working on, I noticed that there were quite a few pages that heavily made use of a particular database table that basically held a set of data that would rarely change. I thought it would be nice to implement a second level cache for  these objects at the ORM level,  I used to use a similar technique with Hibernate and EHCache on my Java projects.

I started poking around the Propel documentation, looking into what features they had to offer in this area and came across a few forum posts requesting that sort of second level cache functionality, but it looked like those features were not going to be implemented until a later release, not going to do me much good for my current project.  But I found a way, and it turned out to be pretty simple.  enter memcache function caching.

Read More >>

A good ORM is hard to find

Every so often in our development lives, we’ll all ask ourselves why we are using an ORM instead of writing SQL by hand.  Most often when people think about using an ORM, it is thought about in terms of keeping a layer of abstraction between the application and the specifics of the database used to store data.  What I think often gets overlooked is that an ORM provides a layer for a framework to wrap boiler plate functionality, to varying degrees, like automatic / declarative transaction handling,  automatic query logging and protection against SQL injection attacks.

Transactions at a glance

Transactions let us define little units of SQL functionality that must occur all together or not at all.  Let’s use the age old example of a travel website as an example.  Let’s say a user wants to book a package that includes an airline reservation, hotel reservation and a rental car reservation.  The customer wants to book all of these reservations together, or does not want to take the trip at all.  So let’s look at a few scenarios which illustrate how this could be handled:

Read More >>