Mura ORM Boot Camp: Part 1

Mura ORM is an Object Relational Mapping tool that allows developers to quickly develop Mura-aware components (or objects, in developer-speak). In this multi-day bootcamp, we are going to examine what Mura ORM is, what you can accomplish with it, and some practical ways you can use it to speed your Mura plugin and extension development.

Mura ORM is a tool that allows developers to quickly develop Mura-aware components (aka objects). By making your components an extension of Mura ORM, you gain access to not only a wide range of functionality, but a huge development time savings. While we have some general documentation available at, this series of posts we will examine the concept of ORM, especially as it applies to Mura, the advantages and functionality it provides, and also take a look at some practical examples you can use in plugins and extensions.

What is ORM?

Object Relational Mapping is a technique that was designed to overcome several object-oriented development complexities. One is the difficulty of storing similar data across a variety of database types (all of which have variations on the SQL we use to store and retrieve data). Another is the complexity of wiring multiple objects together in a related way, i.e. tying a 'door' object and 'tire' object to its parent 'car' object. Third (but by no means final) is the way we work with the related data, often having to do multiple conversions to make the information 'usable'.

ORM solves these problems by wrapping much of the functionality in a 'facade', a sort of common gateway that allows developers to use a style and interface that is common across all types of databases.

What is Mura ORM?

For all its advantages, ORM can also present some difficulties, especially in a platform that is designed to be easily extensible. For instance, the native ORM platform that underlies Mura's server software (based upon Hibernate) expects that only one 'master' ORM application lives under the root directory. Needless to say, this can cause quite a few upsets when plugins (3rd-party or otherwise) come into play. Also, typical ORM platforms require a more rigid application development style, which can be a good thing but also requires a much higher level of development expertise and overall 'application awareness', i.e. knowing how to play nicely with everybody else's work.

MuraORM was developed to allow access to many of the more desireable aspects of ORM (uniform access to data, easy relationship mapping, data portability) but also avoid the difficulties of the "single ORM, multiple applications" dillema.

When do I use Mura ORM?

This is a pretty involved question, though the starting point is actually pretty simple. The most obvious use case is when you need to store custom data inside of Mura, i.e. from a custom form or in a plugin. There are many other use case scenarios which we will examine in future posts in this series, including:

  • automatic integration with the Mura Remote API
  • building complex object relationships
  • integrating with Mura's content feeds, collections and iterators
  • automating data "Bundling", i.e. making your plugins Bundle-friendly

A quick example

Here is a quick example of how you might create a "car" Mura ORM object:

component extends="mura.bean.beanORM" entityname="car" table="my_car" {
  property name="carid" fieldtype="id";
  property name="name" datatype="varchar" length="255";
  property name="createddate" datatype="datetime";
  property name="isrunning" datatype="int" default=0;

... and now a door that belongs to a car:

component extends="mura.bean.beanORM" entityname="door" table="my_car_door" {
  property name="doorid" fieldtype="id";
  property name="style" datatype="varchar" length="255";
  property name="isopen" datatype="int" default=0;
  property name="car" fieldtype="many-to-one" cfc="car" fkcolumn="carid";

In this example, we have a car object, which will store its data in a table called "my_car" (within the same database as your Mura CMS instance). There is also the door object, which will store it's data within a table called "my_car_door". The door is tied to the car via a many-to-one relationship, i.e. there can be many doors tied to a single car.

Mura ORM handles the 'wiring' from this point on. Because the door object establishes a one-to-many relationship with the car, you can call car.getDoorIterator() from the car object without ever having to explicitly create that function, and if you delete the car, any doors associated with it will be deleted as well. All sorts of helper functions such as .save(), .delete() and .update() are available as well.

In the next installment, we'll create a simple standalone example that will illustrate how to create your first Mura ORM extension to Mura, focusing upon:

  • how to instantiate the Mura ORM objects when Mura first fires up
  • how the various relationship mappings (many-to-one, etc.) work
  • some best practice rules when using Mura ORM