In developing ColdPress I’ve come to the point where I need to start building in my database support. If I were building this guy with ColdFusion 9 or some other ORM tools, like transfer then I wouldn’t worry so much about what database engine I used. However since I want this to be as framework-less [...]
In developing ColdPress I’ve come to the point where I need to start building in my database support. If I were building this guy with ColdFusion 9 or some other ORM tools, like transfer then I wouldn’t worry so much about what database engine I used. However since I want this to be as framework-less (word?) as possible I’ve shied away from transfer, coldspring or mach-ii.
So my first thought was to develop using SQL server since I have a feeling that’s going to cover a wide spectrum of the ColdFusion audience. Then I thought about using MySQL to make it truly open source (ie: open source app using open source DB) but then decided that might limit the reach of the product.
Now granted, I’m planning to add in multiple database support after the launch, but just to get to the launch point I’m debating which way to go.
I could use Transfer, but I’m wondering if that’s putting to many requirements on the app? ie: Requirements of Coldpress + the Requirements of Transfer = Requirements of the App
Anyone care to way in on this? I have a feeling I know where this is going to go, but I’m curious what my wide range (read: 3) of readers thing.
8 Responses
ORM layer that supports CF9 ORM or Transfer.
My vote is for MySQL. If you want to follow in the footsteps of Word Press keep it open source.
You will alienate much of your audience going the ORM route.
Hey Chad, just a question to your response. How will an ORM alienate the audience? Is there something that I’m missing there?
I’m not a master architect, but, as long as you create a data access layer, you should be able to create an app that works with any database engine. … at least in theory?
re: “I could use Transfer, but I’m wondering if that’s putting to many requirements on the app? ie: Requirements of Coldpress + the Requirements of Transfer = Requirements of the App”
How is putting the requirement of having Transfer in the app any worse than having the requirement of a specific database?
If you choose a specific database engine, then your requirements will REALLY be
ColdPress + Specific RDBMS
Seems to me that you will be making more difficult for people to use the product if you write it to a specific DB. I can assure you that if it only works with MS SQL that it would never be adopted where I work, nor would I use it for my personal site or any side work.
Even using Transfer will not eliminate all of your cross DB issues. Unlike Hibernate, Transfer will NOT create your DB schema and tables for you, so you will still need a specific create script for each engine.
Finally, as Ben said. If you write your data access layer correctly, then you should need to worry. Try not to use SQL that is specific to certain DBs. Then you only nee dot worry about having specific create scripts for the application.
At the risk of hawking my own (free) wares, this sounds like just the sort of thing for which DataMgr was built.
It doesn’t require ORM syntax, runs on a wide selection of CFML engines, has a small footprint, and supports more databases than Transfer.
Oh yeah, and it *can* create the database schema for you – as well as manage adding any missing tables or columns (handy for upgrades). So no need for SQL scripts.
http://datamgr.riaforge.org/
I was going to suggest DataMgr, but Steve beat me too it. I am planning to use it to do exactly what you want in an open source project of mine. Perfectly fits the bill…not a heavy handed ORM, but just an easy way to support multiple databases.