A problem with ColdFusion ORM and legacy databases
Tags: Coldfusion
It seems I wasn't clear enough in my last post, so I will clarify this up some more.
Although a lot of you questioned why you would have a table with no primary key, and those people are right. However there are a hell of a lot of legacy databases out there, that do not have primary keys in some of there tables.
The problem as I discuss can be found in this previous blog
Using ColdFusion ORM with Legacy Databases
What I proposed to Adobe is that the Id be optional when adding it to the persistent component, this would stop the error from occurring and allow one to continue to map the database without having to worry about the additional adding of the ID.
The second part to the proposal makes the ID field default to an int, with fieldtype of ID and auto increment, and if you don't specify this it will be auto added to the table. This would allow developers to map legacy databases, and not have to worry about something that will be added under the hood.
-
This is a case where there is more going on than you understand, Andrew. Hibernate requires developers to override hashCode() and equals() to handle object identity. This is an issue for anyone who uses Hibernate, and it is definitely not an 'Adobe issue'. There are many different ideas on how to tackle this, but most are complex and all have downsides.
Since CF bases its implementation of those methods on the primary key, a primary key is required for entities. If they didn't do it this way, it would open up a large set of problems in trying to create some other unique way to identify the objects. Given this tradeoff, I'm sure Adobe (wisely) decided to go with requiring a primary key instead of opening up an ugly can of worms trying to implement equals() and hashCode(). While their decision benefits the vast majority, it does mean that those hoping to use the ORM features without primary keys are out of luck.
# Posted By Brian Kotek | 12/9/09 4:58 PM -
Brian - I think you have totaly misread what I am saying. So let me repeat what is in the context of these posts.
If a legacy Database has a table with no PK or ID, all I am saying is that Adobe don't need to force us to add that property.
Adobe can do exaclty what Grails does, and automatically assign the ID to the table behind the scenes.
Reason: Its going to be hard enough for a developer to sit there and remap a legacy Database overtime anyway, and as I stated clearly this would stop the developer from having to stop every 2 minutes and add the ID/PK to that table. Especially if there are a number of tables without PK's
I did make that point extremely clear in my previous posts, and it makes me sad that not one person has read that into the equation!!
If people had read the post that was linked it actually clearly indictates what I am saying, and asking for from Adobe here. Not to mention that I also state that it will be auto added in this blog.
Can people not read anymore!!
# Posted By Andrew Scott | 12/9/09 5:57 PM -
I also don't understand what "Adobe can do exaclty what Grails does, and automatically assign the ID to the table behind the scenes. Are you saying Grails generates a primary key regardless of whether you define one or not?
# Posted By Brian Kotek | 12/9/09 6:22 PM
-
Also, to be clear, is the basis of your complaint that for tables without a primary key, you have to type something like this:
property name="id" fieldtype="id" ormtype="integer" generator="identity";
and you want that to be automatic?# Posted By Brian Kotek | 12/9/09 6:37 PM -
Brian that is correct, if you do not specify the ID field for a primary key, Grails auto generates this for you in the database. It will never be aparat of the Domain Class, but GORM knows about it and provides it to hibernate.
All I have asked from Adobe is something very simple, if the user DOES NOT provide the ID property it is automatically generated and created by ColdFusion, and handled in anyway that it needs to be under the hood.
Does that make it more understandable?# Posted By Andrew Scott | 12/9/09 6:40 PM -
Brian - First of all it is not a complaint. It is an Enhancement Request, to make the life of others who may want to use ColdFusion new ORM features with legacy databases simpler and less painful than it currently is.
Yes, I am asking that Adobe / ColdFusion take care of it under the hood.# Posted By Andrew Scott | 12/9/09 6:45 PM -
BTW BRian did you read this post at all?
http://www.andyscott.id.au/index.cfm/2009/11/6/Usi...
It would have answered a lot more, and I wouldn't have had to re-explain myself.# Posted By Andrew Scott | 12/9/09 6:52 PM -
Andrew,
My 2c worth: I would rather spend the 30 minutes to write the SQL script that adds a PK to every table than open up the database to schema modification by the app server. There are many situations where proposing the latter would pretty much get you run out of town on a rail.
# Posted By Jaime Metcher | 12/9/09 10:11 PM -
Jamie, thats the beauty of it. You can either add it or not and it becomes your personal choice.
Most people who know me know that I will compare it with something that has been doing this sort of thing for over 4 years now. Grails ORM can be used as a guide to how they do things, and I can tell you this that there is a lot of things that Adobe can learn from GORM and how they got around situations that we are going to be facing in the next few years.
So the logic is, if they have come across it why did they make it that way?
Again its because of legacy databases, and minimising the work that the developer needs to get it up and running. And they key issue here is what we call RAD, if Adobe want to regain that crown this is the things that they need to serioulsy consider.
# Posted By Andrew Scott | 12/9/09 11:06 PM
TweetBacks