It has been over a month since I released 0.4 of Transfer, and there has been a lot of work on Transfer been done to get it ready for 0.5.
First of all, I'd like to extend a big thanks to my current employers, NGA.net , who allowed me to open source the development on Transfer that was required for a current project. You guys are great.
Second of all, I would just like to say – I've put a lot of time and effort into this release, so I would greatly appreciate it if you could take some time to download and give it a good test and general bash around. If you want to provide feedback there is a mailing list , a forum , a bug tracker , and a feature request tracker , and failing all that, you can send me an email directly!
I want to hear your feedback, whether it is good, bad, or otherwise. One of the initial reasons I started writing open source code was as a learning exercise (one of which I recommend quite highly), so your feedback only helps in that process.
With this release, I have written a cfpetmarket application using Transfer. All I have yet to do on it is write the readme, and bundle it up, so it should be released in day or two.
There is also the tBlog example application that has been updated to use the new code.
On to more important things however – What's new in this release?
- Postgresql support
I've implemented PostGres support, and included setup SQL with the tBlog application for it. I haven't spent much time with PostGres as a database, so anyone who uses it regularly and wants to test out how Transfer handles on it, please do.
- The ability to control the caching of objects within Transfer, down to an object and scope level.
While many people will probably never need this functionality, you can now configure the caching of Objects down to numbers, time, as well as pushing the cache to shared scopes like request, session or application. Very useful if you have multiple copies of Transfer running in a Application, but you want to share caches.
- Now getIsPersisted() and getIsDirty() methods on TransferObjects to determine if an object has been persisted in the database and/or had it data modified respectively.
This was more for internal use within Transfer, but it is handy to be able to see if objects have been modified and/or have been created in the database.
- If Object have not been modified since their last commitment to the database, the Transfer.update() will not fire events, or run the database update.
This is useful if you are writing cascading save() calls on composite objects. You can now safely call save() on an object, knowing that it will only hit the database if the data has been changed.
First off, thanks to much thanks to Aaron J Lynch for allowing me to use and modify his wwwObjectDoc tool for this. This is a tool for generating documentation on the Business Objects that Transfer creates for you. I use this a lot when using Transfer, as I can't remember what property of onetomany relationship has created what.
- If the primary key has been set before inserting, it overrides Transfer's population/retrieval mechanism, and the object is inserted under the set primary key.
This is something I came across when I was writing cfpetmarket – I needed to override all the primary key handling of Transfer, and manually set it. So now, if you use the setter for the Primary Key on a TransferObject, Transfer will try and insert the record with that primary key, rather than try and retrieve it from the database, or try and generate it.
- Some better handling of database 'null' values being turned into values like dates, GUIDs, numbers etc (Not much really you can do to emulate 'null' however).
This was a bit of a bug. Transfer didn't handle NULL values coming out of databases very well. Now NULL values result in default values.
- onetomany relationships can now removeParent, and hasParent relationships.
- manytoone relationships now have has, and remove functions.
I'll lump these two together. Now you can have compositions that may or may not have objects in them. If the object is not set, Transfer will attempt to insert/update NULL values into the relevant foreign keys.
- Removal of the use of a preparedStatement on Selects, and reverted back to CFQUERY, which is much more performant on memory.
Originally Transfer used a Java preparedStatement to run its SQL queries. Looking at this again I realised it wasn't necessary, so I moved it back to cfquery, and found a performance increase.
- Fixed bug where composite objects more than 2 levels deep would fail
This was a nasty bug, and has now been fixed. I wrote some code that made no sense.
- Fixed bug where composite objects with the same named columns would fail
This was also a nasty bug, as has also been fixed.
There are a few more bits and pieces behind the scenes – but a full change log can be seen here .
On to new and better things – what can you expect in the next release?
- Oracle Support
I wanted to get this out in the last release, but I had a need for the caching controls, so that took precedence. The hooks are in place to write this code, it just needs to be done and tested.
- Lazy Loading
I've been bugged and bugged for this functionality, and I've finally realised that this really needs to be in there. In some ways I wonder if I went the wrong way by not implementing this in the first place, but my software design is proving to be quite flexible, and I have quite a few ideas how to get this ball rolling.
- Cascading creates, updates and saves.
This would be really handy, so I'm going to do it.
Now that this has been released, I can write up the rest of my blog posts on Transfer, and I also have a CFUG presentation on Transfer coming up which I will make the contents of available for download.
And of course – this website runs on Transfer 0.5 right now.