I recently noticed that Galleon has been used as a sample application for a few frameworks. Showing a complete lack of originality, I decided to do the same thing with DataMgr on Galleon. Where relevant, I changed the code from cfquery calls to DataMgr calls. The goal was to change only the business layer internals and leave the rest of the code unchanged.
I did have to make a few changes to Galleon before I could start in earnest:
- I had to change galleon.cfc to load DataMgr and return it in getSettings().
- I had to change the setSettings method in each model CFC to put DataMgr in variables.DataMgr.
- I put XML to define the database in galleon.cfc and passed it into Datamgr.loadXml(). This step could have been avoided, but provided me with some benefits, so it seemed worthwhile.
Note that none of the changes to Galleon are outside of the "cfcs" folder.
Ray had a few queries which I chose to leave alone rather than take them time to grok them fully. Other than that, I was able to replace most of the queries in Galleon.
I didn't track the time involved, but I did make the entire transition in one day.
So, what was gained from the trouble?
More Database Support
Galleon currently runs on Access, Oracle, MySQL and PostGreSQL. By modifying it to run on DataMgr 2.2, it gets additional support for PostGreSQL and Apache Derby. Adding support for a new database could be done by creating a new database adaptor for DataMgr.
I say this with some trepidation as Ray is really good at making an easy installation. The process to install Galleon requires running a SQL file to set up a database (or using the included Galleon.mdb file for MS Access). This is great for a first installation.
Galleon also includes the ability to choose your own table prefix. If you decide to do that, however, you have to edit the SQL files before you run them (not to bad, a quick find/replace should do the trick).
When upgrading to a new version, you may have to manually add some new columns.
Note that this functionality does require the datasource to have both CREATE and ALTER permissions. I could have also created a fall-back to return the SQL to the user in the even that these permissions weren't available (see CodeCop for an example of this).
This will use whatever prefix is set up in the settings and will automatically add new tables and columns on an upgrade.
I did have to add about 400 lines of code to galleon.cfc to bring about the automatic installation that I just mentioned. This obviates the need for nearly 600 lines of SQL and the 450K forums.mdb file. Additionally, I removed about 500 lines of code from the CFCs in in the "cfcs" folder.
No Need for a dbtype setting
The removed code consisted mostly of queries, but often had conditionals based on the dbtype setting. DataMgr handles all of the differences for which dbtype conditionals existed in Galleon, so those are no longer needed.
Moreover, because I used DataMgr 2.2 I was able to take advantage of automatic database detection (thanks again Mark Mandel) allowing DataMgr to determine the database being used from the datasource.
So, no more need for the dbtype setting.
No Other Impact
This isn't really a benefit, but bears mentioning. I didn't have to change any code outside of the "cfcs" folder. I also limited myself to changes that would allow this version to be in the Galleon upgrade path. That is to say that you should be able to directly upgrade from any other version of Galleon to this one.
That being said, I didn't undertake this project in the hopes of getting people to switch to a version of Galleon running on DataMgr. Rather I wanted to provide a fair comparison of DataMgr to a more traditional approach. I would suggest downloading this (using the "download" link at the bottom of this entry) as well as Galleon 2.2.3 (the version on which this is based) for comparison.