How to add ORM to a PHP legacy project?

Question

We're working on a PHP project, which has been in development for more than 2 years, and now the team is ready and feel the willingness to switch the development on to an ORM. Because it really speeds up the development and allow you to operate by Objects and not think in terms of SQL code and database tables most of the time.

We have decided to choose the Doctrine ORM, because it has YAML data fixtures load - we need it very much for our unit-tests.

The main fear I have, is that using of a new ORM framework can slow the site's performance. We can't make a shared connection between current database abstraction layer (which uses pg_connect syntax, not PDO-compatible). The database connection mechanism can't be switched to PDO-compatible, because there are lots of SQL code incompatible with PDO_SQLITE syntax.

So, as I understand it, if we will start using it, it will double the number of database connections. I'm not sure database server will be able to handle this.

What would you recommend us to do in this circumstance?

Answer 1

Of what relevance is PDO_SQLITE?

Unless you actually plan on using the SQLite driver then compatibility is not mandated by PDO.

If you aren't going to use SQLite then I would make the legacy database layer PDO compatible and re-use the connections until you can fully migrate to Doctrine.

That said, the level of connections is not going to be your only performance concern moving to an ORM. They are inherently inefficient so I'd expect slower queries, higher bandwidth use between application servers and the database servers and higher memory use at the application level due to redundant data inevitably getting selected. Depending on your current setup, the above may or may not be issues.

You should probably take that last paragraph with a pinch of salt though because they are just traits of ORMs in general and not Doctrine in particular, with which I've had no experience.

Answer 2

The obvious thing you can do is not open a database connection until you need it. I personally use code like this:

public function connect() {
  if (!defined('CONNECT')) {
    mysql_connect(...);
  }
}

public function db_query($query) {
  connect();
  $ret = mysql_query($query);
  if (!$ret) {
    die(mysql_error());
    error_log(mysql_error() . ' - ' . $query);
  }
  return $ret;
}

to reduce the amount of repetitive and to only open a connection when you need one.

In your case you then need to break off the smallest chunk you can to begin with. Ideally it should be a vertical slice, meaning this slice will do almost all of its database work with the new code and very little with the old. This way you can minimal doubling up of database connections and this lets you build up some skills and get some experience too.

Beware though, ORM is not by any means a panacea. You may hate SQL and find it fiddly and error prone but you are, for the most part, simply trading one set of problems for another. I personally think that while ORM can be useful it has been overhyped and is more of a false economy than many either realize or are willing to admit. I wrote more on this in Using an ORM or plain SQL?

I'm not saying you shouldn't do it. Just don't go in thinking it'll solve all your problems. Also, since this rewrite won't actually change the functionality at all (from what you've described) I'm not sure if the cost of doing so compares favourably with fixing what's there already. Too many unknowns to say which way your situation will go.

Answer 3

Well, yes and no – your DB connections will only be doubled as long as you have both a non-PDO and a PDO connection.

I'm not sure what you mean with the PDO_SQLITE reference, since SQLite is a wholly different database than the PostgreSQL it seems you're using now.

You should be able to run your current queries through PDO::query just as you do today unless you are doing something very wrong :)