My latest article for the Adobe Edge journal was just released. It covers the basics of starting a new ColdFusion ORM project using some of the features within the recently released ColdFusion Builder. The article walks through setting up your project in Builder to installing extensions, specifically I use Terrence Ryan's Appatacular extension which should be released soon (but is available in his article on the Developer Connection). Much of the ORM code is generated using this tool but I also show how you can manually manage ORM and allow it to make the necessary changes to your schema for you. If you are new to either ORM or ColdFusion Builder (or are just curious about Apptacular), this should be a worthwhile tutorial for you.

On another note, if you are interested in learning Flex and using Flash Builder, you can also catch me and a number of other great developers interviewed by Julie Campagna in the featured video on the Edge. The video covers ways to get started learning Flex and discusses a number of great resources available to you.

Article: Object relational mapping in ColdFusion 9 and ColdFusion Builder

Video: Getting Started with Flex

ColdFusion ORM has a powerful feature that allows you to include properties in your object that contain computed data using a formula. For example, the application I am currently working on has Poll objects that contain Answers (as in the response options) and responses (i.e. the user submitted vote). In this scenario, you may want to allow that when you retrieve a Poll object it has knowledge of how many votes have been cast for that poll. In addition, you would likely want each Answer to have knowledge of how many times it has been voted for. In doing so it would be very easy to render the poll results. In this scenario, your Poll would have a computed property for your Poll called totalVotesCast and your Answer object may similarly contain a computed property for responseCount (the names aren't important here...so don't focus on it). This is actually very easy to do using ORM computed properties, with one gotcha that caught me.

Given that I am finally delving deep into ORM for a real application rather tha proof-of-concepts or demos for articles, I am finally able to make idiotic mistakes in configuration that cause me days worth of grief. Thus why I am calling this post the first in a series on my dumb mistakes in the hopes that you don't have to follow suit. Today's issue had to do with configuring a one-to-one relationship and blindly overlooking what was properly in the documentation (I think I may have stared at it too long).  Here are the key items in the configuration of Employee and OfficeCubicle from the documentation example (I will note what I screwed up and what it caused after):

• Property of child "officeCubicle" in parent "Employee" set to "one-to-one" and pointing to "OfficeCubicle" component (that one is easy I know)
• ID in child component (OfficeCubicle) set to generator="foreign"
• ID in child component (OfficeCubicle) set with params="{property='Employee'}" (this is not so clear, the property is the name of the one-to-one relationship property within the child component - not the name of the component necessarily)
• Child component (OfficeCubicle) has relationship property defined as "one-to-one" and points to parent CFC (Employee) (another easy one)
• Relationship property in child is set to constrained="true"

My dumb mistake? I had constrained="true" on the relationship property in the parent. This meant that anytime Hibernate tried to insert an Employee (in this case) that it would give me a "violation of foreign key constraint" error because a corresponding OfficeCubicle record did not yet exist. It's a totally simple and obvious rule to remember that the constraint should be on the child and not on the parent [smacks self in head]. Once I set that properly everything worked as advertised.

As a sidenote, I am using an Apache Derby Embedded database for some local testing when creating my objects (with Hibernate set to manage tables). Trying to change the objects to fix this issue caused me to get errors saying "could not export DDX." The issue, which I could see in the console, was that Hibernate created a Hibernate_Unique_Key table in my schema and it kept failing on the drop constraint and drop table for that table somehow (I think this table relates to my ID's being set to "native" but not totally sure). Anyway, simply deleting the Derby DB files and recreating them in the ColdFusion Admin seemed to resolve this (though that may not always be feasible it would be for a testing scenario like this).

Anyway, hopefully this post will stop others from repeating my stupidity...more dumb mistakes to follow I am sure. :)