You can now watch my presentation at your leisure. Enjoy. The embedded presentation below (via SlideSix) contains the slides, a link to the recording URL, and the code as an attachment. I forgot to post the MySQL db, so if you need that, give me a holler.
The recording URL is: http://experts.na3.acrobat.com/p63422033/
It's been a while since I blogged about Transfer, but I finally got time to look into caching and performance issues with Transfer. I'm pretty impressed by what I've found. If I had known about some of this back when I was working on CFLib 2008, I probably would have done things quite a bit differently. (In fact, I may take a look at re-building things a bit and blogging about the changes.) Here is a quick summary of some of the things you can do to improve performance issues with Transfer.
In all my posts so far on Transfer, this is the one I was most looking forward to. I had known, in general, what Transfer did and how it works... kind of. But the event model was something I was completely in the dark with so I couldn't wait to start playing with it. Now that I have, I can say I'm both impressed, and a bit disappointed.
Justin asks:
I hate to get into 'better'/'proper' type things without being real clear up front that this is normally a matter of opinion. Being still new to Transfer, I'd love to hear what others think (whether they use Transfer or Reactor or some other ORM). Here is my opinion.How do you best recommend setting up your application structure for a Transfer app?
For example let's say I'm building a CMS for blog posts, so there are essentially pages to list, create,update & delete
Would you create a Blog.cfc and call transfer methods from that CFC or would you call the transfer methods directly from the .cfm pages
Is one way better than the other? Is one way more 'proper' than the other?
Today I get to talk about my favorite Transfer topic (although events may supplant it) - Decorators. No, I'm not talking about the people who come in and hang wallpaper or rearrange your furniture. Rather, decorators in Transfer allow you to extend and build upon the TransferObjects automatically created for you when you get data via Transfer.
In all my entries on Transfer so far, we have yet to actually write a line of SQL, and believe me, I don't mind that one bit. But as you can probably imagine, there are definitely cases where you do need to break down and write some actual SQL statements. The biggest example is search. My last entry talked about how you can get data based on properties, but it only worked for exact matches, i.e., where name was a specific value. Transfer provides a way around this with the feature I'll cover tonight - Transfer Query Language.
Getting Some with Transfer
Nov 14
In today's Transfer entry I'm going to talk about getting objects in Transfer. I had previously talked about the get method and how it can load an object via a primary key, but what about other methods of finding objects?
Welcome to my third post on managing relationships with Transfer. If you want to get caught up on the earlier ones, or any of the other entries in this series on learning Transfer, please see the Related Blog Entries section below. Previously I talked about ManyToOne relationships (multiple employees were linked to single departments) and ManyToMany relationships (multiple employees linked up with multiple benefits). Today I'll cover the final variety - OneToMany.
In my last post on relationships in Transfer, I talked about the ManyToOne relationship. I defined the Department object and associated employees with a department.
For today's post, I'll be talking about the ManyToMany relationship. This relationship exists when you have multiple connections between two objects. The example the Transfer docs give, and the I think that makes the best sample (especially considering where you are reading this), is the idea of blog entries and categories. A blog entry can have more than one category. On the database side, this is done via a join table with one column pointing to a blog entry and another column pointing to a category.
As I mentioned in yesterday's blog post, our simple application with one table isn't terribly realistic. Easy to build - yes. Real world? Not even close. Today we are going to work with some new data in our Transfer sample application, and talk a bit about how Transfer can help manage relationships between types of data.