Enrico Stahn

I mentioned that we’re migrate our application from pure SQL to an ORM-Layer. Many of the existing functions working with column names of the database tables. Sometimes these column names are used hard coded or directly linked to the view layer. The actual problem is that we used the opportunity of the migration to unify the denotation of our tables and column names via the doctrine alias functionality. At the end we had functions using the old syntax and models with a new stylish unified nomenclature.

Fortunately it’s all OOP :)

The f need a way to get the data from a given “Array”, but with the real column names instead of the new field names. The Doctrine_Record implements the ArrayAccess-Interface, which solves the problem that Doctrine_Record object should behave like an Array. The compatibility issue is solved through a small decorator which is currently not more as a proof of concept. The decorator change the functionality of the implemented ArrayAccess-Interface so that will accept real column names.

/**
 * A Doctrine_Record uses field names instead of columns names
 *
 * The RecordColumnNameDecorator change the functionality how
 * you call data from a Doctrine_Record. You can use the original
 * column names instead of the field alias.
 *
 * @author     Enrico Stahn <stahn@rib.de>
 * @version    SVN: $Id$
 */
class RecordColumnNameDecorator extends Doctrine_Record
{
    protected $record;

    public function __construct(Doctrine_Record $record)
    {
        $this->record = $record;
    }

    public function offsetGet($key)
    {
        return $this->record[$this->record->getTable()->getFieldName($key)];
    }

    // ... Implement the rest of the interface
}

Example:

// old: ugly_tablename.ugly_column_name
// new: foo.bar
$a = new Foo();
$b = new RecordColumnNameDecorator($a);
echo $a->bar;
echo $b->ugly_column_name

easy-peasy :)

Tags: ,

The next months are full of hard work because we have to master a huge migration task. We migrate all SQL-Statements to an ORM Layer. The application is already a bit long in the tooth and has approximately 8000 queries.

The database itself has some strange design issues and some of them are incompatible with the ORM layer. One of this issues is the lack of a primary key at some tables.

In PostgreSQL we can solve this with the following steps:

  • Add a column with type integer to your table
  • Create a sequence
  • Update the column table with sequence values
  • Set the necessary column properties (e.g. default, not null, etc.

Example for table “foo” and column “id”:

ALTER TABLE "public"."foo"
  ADD COLUMN "id" INTEGER;

CREATE SEQUENCE "public"."foo_id_seq";

UPDATE foo SET id = nextval('"public"."foo_id_seq"');

ALTER TABLE "public"."foo"
  ALTER COLUMN "id" SET DEFAULT nextval('"public"."foo_id_seq"'::text);

ALTER TABLE "public"."foo"
  ALTER COLUMN "id" SET NOT NULL;
  
ALTER TABLE "public"."foo"
  ADD UNIQUE ("id");

ALTER TABLE "public"."foo"
  DROP CONSTRAINT "foo_id_key" RESTRICT;

ALTER TABLE "public"."foo"
  ADD PRIMARY KEY ("id");

Recommended Reading

No Google Reader feed was found with the provided ID. Please validate the ID in plug-in configuration.

Twitter

Posting tweet...

Powered by Twitter Tools

About

I'm a passionate Software Developer who loves juggling around with new technologies. This website is about my technical daily grind, problems i stumbled over and some private stuff.