Andrew's ramblings

ColdFusion ORM problems to watch out for

Tags: Coldfusion

Well it is no big secret that Adobe rushed ColdFusion out the door for Max, and with my last blog post I stirred up a real hornets nest in the community. Do I care, no I do not. A spade is a spade with me.

But that doesn't mean the product is all bad, it just means that you need to be aware of certain things that can mean the difference between insanity and feeling sane.

With any new feature there is always going to be teething problems, and the ORM part of ColdFusion will be no exception to this. It is from what I can tell very bug ridden, and there are some things that will need to be taken into consideration when you start planning your project with the ORM in mind.

So lets look at the first problem, and this can be the most serious bug in the ORM if you are not aware that it is an issue.

While in development, if you use the dropcreate option to the ormsettings, you must take into consideration that for some reason the database will not be created with the columns being what you might think.

For example lets look at a common development problem.

While developing a domain class (persistent Component) for a project I am working on, I created the following property.

Now when this is created it looks fine, however this has a size in the db as being 19 chars in length, which is the default size for this type of field. Well that would normally not be a problem, until change it to this.

In the above example I decided that I did not want a true DB timestamp, and I needed a string representation of it in the database. Now as I was using the dropcreate I did not think anything of this, because I knew the default length of the string would be 255 in length. That was a big assumption on my part that saw my application falling over in areas that I could not understand. It took me hours to find that the problem was actually ColdFusion and not my Code.

The problem is that the string kept the length of what it used to be, 19 chars in length. God knows why, or should that be only Adobe knows why!!

But the point here is that we are going to have to be more vigilant when switching betweens types, because other parts of the application might, or more to the point will just fail.

The second most important part that is going to trap a lot of people, is the length of the string in ColdFusion and the database. So let me explain first the defaults.

When we create a property and assign the type to string, we would normally know after reading the documentation that this would default to 255 chars in length. But what if we want it to be more!!

Well that is not a problem, what is the problem is that ColdFusion knows nothing about constraints. And by that I mean telling it you expect it to only have n length means nothing to ColdFusion.

In my last post the product manager of ColdFusion said something to me that made me cringe, his words was along the lines of that as being part of a program you had ample opportunity to test and report your findings. The major problem was that what Adam didn't know was that I was doing just that, but all I got from the other people in this program was that ColdFusion is not Grails.

So I gave up, and now that the product is released I can no openly speak my mind on the subject.

One of the things that Grails does (oops I better be careful here, because there are many who don't like it when I compare Grails and ColdFusion) is that it knows about constraints. By that it sets up a constraints definition so that it says, should this property except null values, can we have a max size amongst other things. ColdFusion sort of follows this rule but it is extremely poorly implemented, and you really need to know that.

Because it can create headaches for your applications if you don't understand that this is a serious limitation when it comes to the initial release of ColdFusion 9. So even though you set a property to be a string and you only want a maximum of 1000 chars in that property, ColdFusion couldn't care less. As long as it can fit into the database, ColdFusion is happy enough.

Even though ColdFusion has an attribute for the ORM or persistent components properties, it is not adhered too in anyway shape or form. Adobe were not interested in hearing anything that was Grails related, nor was anyone else. So be very careful about this problem.

Grails when it creates the following

Later has a constraints section that can define how much this property can hold, the maxsize attribute tells the ORM or hibernate that it can't accept any more into the table for this field that exceeds that value. Which Grails handles before sending it off to hibernate.

And that is an issue for ColdFusion, because ColdFusion can do something similar and it is like this.

Now the problem is that hibernate will convert that to a longtext for the database and so will ColdFusion, the difference between ColdFusion and Grails is that Grails still has the definition of that constraint in the GORM  (Grails ORM) where ColdFusion doesn't care anymore.

So the length of the string as far as ColdFusion is concerned can be as long as 10,000 characters in length and still happily put it into the table, where Grails will not put it into the field.

So when developing your first CF-ORM remember ColdFusion has just introduced this and it is and will be at this point in time full of things that one can expect to be not catered for or totally broken.

Anyway please do take this as a warning, because it will until Adobe fixes the problem and gives true constraints in the persistent components, cause major headaches and not to mention you will have to write a hell of a lot more code than you think. Which is sort of contradictive to Adobe telling us we write less code and ColdFusion is promoted as being RAD, in some aspects it is, but when it matters the most it certainly is not.

Tweet