Another ColdFusion 9 ORM bug, Adobe says no

Tags: Coldfusion, CFORM

While playing around with ColdFusion 9 and the ORM features I suddenly changed my mind, on the property definition for the ORM and got some very unexpected behaviour.

The Adobe Software Engineer claims that this works for him, and I am at a loss to explain to him that this is still a bug.

The number one thing I always do in development is use the dropcreate option for dbcreate for all new projects, this seems to be creating a number of bugs in ColdFusion 9. But this one is really something that I think is a major bug in the ORM implemented in ColdFusion 9.

To duplicate this bug is very simple, the first thing we need to do is create a user.cfc that is persistent that looks something like this.

property name="username" ormtype="string" unique="true" fieldtype="id";
property name="password" ormtype="string";

This will create what you expect and the primary key is on the username, however I changed my mind and modified the code to be this instead.

property name="id" ormtype="int" generator="native" fieldtype="id";
property name="username" ormtype="string";
property name="password" ormtype="string";

Now what I did not expect here is what the actual problem is, I would have expected that ColdFusion 9 would have modified the table to move the primary key over to the ID. Instead what we get is a composite key, comprising of a primary key on the ID field and one on the username. Even though my new persistent component is saying otherwise.

I am a little mystified how Adobe engineers can claim that this is normal, and works as expected.

Anyone else?


TweetBacks


Comments (Moderated) | Add Comment

  • Henry Ho's Gravatar Have you tried dropping the tables yourself and let CF recreate the tables?
    # Posted By Henry Ho | 12/15/09 2:12 AM
  • Andrew Scott's Gravatar Yes Henry I have, but what does that prove?
    # Posted By Andrew Scott | 12/15/09 2:15 AM

Comments (Moderated) | Add Comment