Metadata specification

For an ORM to work, there are different data models that has to be kept in sync: the object model defined in the PHP source code, the relational model represented by the database schema, and the mapping metadata which configures the ORM to translate between the two.

As with all duplication problems, some of this models may be derived from their equivalents. For example, the simplest ORMs infer the object model from the list of tables in the specified database. There are more sophisticated approaches, like defining at least the metadata to configure the ORM and generate the object and relational model from these mapping configuration. Doctrine 1 and other ORMs makes wide use of this technique.

An even more resilient approach is to define explicitly an object model and its metadata in the form of annotations embedded in PHP code or XML documents, and to generate only the relational schema (as Doctrine 2 does.)

Visual design of metadata

The application reviewed in this article, ORM Designer, is a visual design tool for PHP object-relational mappers. Developers can define an unified model via a graphical interface, and derive the ORM configuration (object and relational model plus the mapping metadata) automatically from the unified model.

Visual designing tools have to be taken with a grain of salt, as there is no fine control over their results when used for code generation. Furthermore, the generated products have to be kept in sync with the evolving unified model via regeneration, and this raises issues with further editing.

ORM Designer pays particular attention to these issues. The unified model is stored in human readable XML, and it is the source of all the generated code. The advantage of XML over a binary format resides in the possibility of diffing different versions of the model and storing it efficiently in source control systems. Of course this unified model can be exported in a format thatcan be understood by the ORM. In the case of Doctrine, which is the primary target of this designing tool, Yaml would be the format of choice.

The ORMs currently supported by ORM designer are Propel and Doctrine, plus the model system of CakePHP (Zend Framework and symfony projects usually employ Doctrine to implement ORM functionalitites). Support for Doctrine 2 is under development, because due to the versatility of the ORM there are some issues in implementing visualization for features like inheritance and annotations.

ORM Designer runs on nearly every platform: Windows, Mac OS X and Linux with wine. I have tried it on Ubuntu 10.04 and there no issues on functionality nor slowness due to the use of wine. The graphical interface is very close to the simplicity of Microsoft Access, but of course the generated source code is much more powerful as it can be used on many different enterprise database vendors.

The abstraction of having every object available in memory

The Data Mapper pattern is in general very flexible: you can create domain classes as Plain Old PHP Objects, which do not extend any abstract base class; subsequently a Data Mapper layer abstracts the database as a generic storage. Though, application-specific Data Mappers are generally boring and repetitive to write, while also being prone to errors.

With Doctrine 2, you still produce an object model and, with the aid of mapping metadata in the form of small XML files or annotations, the schema of the related relational database  is inferred, while the client code in the rest of the application lives the illusion of an in-memory object graph.

You can largely ignore the database, considering it an implementation detail. The schema can be generated and created from the command line, and there are more than one thousand unit tests to target the different database management systems used as back ends (MySQL, Postgresql, Oracle, Sqlite) to avoid unpleasant surprises. Depending on your vendor of choice, database-specific SQL code will be generated for the creation phase and during querying.

Underlying technology

Doctrine 2 goes to a great extent to avoid introducing unnecessary code for persistence purposes only. The objects’ content are accessed and reconstituted via reflection, avoiding the use of getters or initialization methods, while part of the object graph can be substituted by lazy-loading proxies which take the place of real objects by dynamically subclassing them; however performance can be problematic if you over use this feature. Moreover, this first beta of Doctrine 2 is the first to support constructors with non-optional arguments; objects are recreated via cloning to bypass the constructor call, further extending the metaphor of objects that never leave memory.

If you have already been using Doctrine 2 in its alpha stage, there is a guide to the upgrade from the alpha 4 version. The official documentation is also fairly good for a project which is not yet officially stable. If you want to contribute to the codebase instead, the development has been moved on github and only a fork divides you from producing a useful patch.

Background

The in-development HTML5 specification is becoming more and more supported by browsers such as Firefox, Safari and even Internet Explorer. Together with other standardizations, the specification defines a per-host relational database for data storage on the client side, to be accessed via JavaScript without any additional requirement than SQL knowledge.
Currently SQLite is used by all the browsers’ implementations, as it is the most popular lightweight relational database.

However, the available data model is not really limited to the relational one.

The solution

As often is the case, where there is a relational database, there is also an object-relational mapper. In JavaScript every variable is an object, so it makes sense to build an object-oriented application model, and transparently persist the data.

Thus the need for a DataMapper, like Impel, to store these objects automatically in the native database via metadata provided in the source code. Of course Impel comes with an automatical synchronization package for updating the rapidly changing schemas distributed all over the client machines. And it runs on the iPhone, as the authors like to point out.

Technology overview

Impel is built over MooTools, which is a required dependency. The API is modeled on Propel. Propel was one of the first object-relational mappers for PHP 5.

The original API is modified to accommodate an asynchronous model, which the JavaScript interpreters require. Blocking calls in JavaScript do not work very well, since with the usage of simple method calls the browser would effectively freeze while expecting that the database computes and returns its query result. Asynchronous model means that handlers (anonymous or named functions) are registered on querying, and are called when the result is available, fitting in the event-driven paradigm of JavaScript programming.

Impel is indeed a bleeding edge technology, but a standout in the new HTML5 environment. It fills the gap between JavaScript objects and the native local storage of HTML5, a significant feature especially for early adopters.