Dan's Shorts

Managing the Transfer Cache with Clones

I had a bit of an adventure when dealing with the Transfer cache. This post sums up my misconceptions, and how I get things working the right way.

Read complete post

2 comments | Posted by Daniel Short on Jul 21, 2008 at 12:00 AM | Categories: ColdFusion - Transfer -

Dealing with Stamp and StampUpdated with Transfer

Continuing work on my top secret app and learning CCT (ColdBox, ColdSpring, and Transfer), I'm going to describe how to handle stamp and stampupdated columns in your tables. In every table that I have in any database I build, I have both a stamp and stampupdated column. The stamp column tells me when the record was originally created, and the stampupdated column tells me the last time that data changed. Both of these columns have a default value of getDate(). Here's the colum definition for an example table: CREATE TABLE [dbo].MyTable( [ID] [int] IDENTITY(1,1) NOT NULL, [Label] [varchar](50) NOT NULL, [stamp] [datetime] NOT NULL CONSTRAINT [DF_Items_stamp] DEFAULT (getdate()), [stampupdated] [datetime] NOT NULL CONSTRAINT [DF_Items_stampupdated] DEFAULT (getdate()), This works great on initial insert, but doesn't update the stampupdated column on each UPDATE. So to handle making sure the stampupdated gets taken care of properly I create a trigger on each table like so: CREATE TRIGGER [dbo].[MyTable_Update] ON [dbo].[MyTable] AFTER UPDATE AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for trigger here UPDATE MyTable SET stampupdated = getDate() FROM Inserted WHERE MyTable.ID = Inserted.ID END Now to handle these properly in Transfer, I can't have transfer updating and inserted those values, because the database is responsible for those actions. So let's take a look at what would be the standard property tags for those two columns: So with the above property tags, when I save a transfer object it's going to run either an INSERT or an UPDATE statement that will change the stamp and stampupdated columns. But since the database is responsible for this data, that means that 1) Transfer is doing unnecessary and potentially incorrect work and 2) That the values that the database creates won't get back to the Transfer object. To fix that we need to add a few additional attributes to each of these property tags. I've now told Transfer to ignore the stamp for the purposes of INSERTs and UPDATEs, and to update the Transfer value when a new record is inserted. I don't need to refresh the value on UPDATE, as the stamp value should never change. On the stampupdated column however, I'm ignoring the value for both INSERTs and UPDATEs, and I'm also refreshing the value on both. This means that on an update the workflow of the UPDATE works something like this: * Call Transfer save method * Record is UPDATEd in the database * On UPDATE trigger fires and updates stampupdated column to the current date * Transfer queries the update record, picks up the new stampupdated column, and updates the stampupdated property of the object to the new value * Transfer gives me back a fresh object with the new values So that's how I handle all of my stamp and stampupdated columns in my database. You can find out more about the Transfer config options at the Transfer ORM docs site.

0 comments | Posted by Daniel Short on Jul 20, 2008 at 12:00 AM | Categories: ColdFusion - Transfer -

Getting Moving Again...

Things have been rough on the work front lately, but I'm starting to finally move forward again. It's been about 6 months since I've actually built anything worth mentioning, and I'm finally starting to get back into it :)

So today I'm working on a top secret app using ColdBox, ColdSpring, and Transfer, the super trifecta of ColdFusion development (that's my own personal opinion, your mileage may vary) and I'm starting to get the hang of it. I'm doing all of this development locally on my Mac using a VMWare installation of Windows Server 2003 and SQL Server 2005 with Eclipse as my development IDE of choice.

As I move forward, I'm hoping to have the time to post some of my thoughts here on how it all fits together. I've done lots of OO programming over the last two years, but nothing quite like the "pure" MVC that ColdBox and the rest of the frameworks work within. I've generally developed with a View and a Model, but never with the controller in the middle. The new app I'm working on will have external non-CF clients that will need access to the model and a completely different set of views, so I think this is really going to take my development skills to the next level.

So as I move forward, my sincere thanks (already) to Luis Majano and Mark Mandel for all the work they do in both building and supporting their frameworks.

0 comments | Posted by Daniel Short on Jul 19, 2008 at 12:00 AM | Categories: ColdFusion -