Cool, I am excited for the flexibility this brings! I know I am biased, but I think the getXyz() decision is a smart direction to take things.
For those who are worried about retrofitting, I think it is a simple as just adjusting your aliases in the configuration file to include ‘Record’ in the naming. - Shannon ----- Original Message ----- From: Doug Hughes To: <[email protected]> Sent: Sat, 15 Apr 2006 12:11:14 -0400 Subject: [Reactor For CF] Imporant changes commng to reactor this weekend Everyone - This message is to let you know of the following changes that *will* break your code. These changes will be published some time today or tomorrow. (As soon as I get them working with two of my projects and the samples.) The changes are: For a month or so now I've had record objects cache the in instance variables the results of calling getXyzRecord() or getXyzIterator() or getXyzLookup(). This has caused me no end of headaches that I've been trying to ignore but which have ticked me off enough to finally make me do something about it. Here's an example of the issue: I have a UserRecord that hasOne AddressRecord that hasOne CountryRecord. When the User logs in their corresponding UserRecord is stored in their session. The user goes to edit their profile to change their address. They view their profile and see all the correct information. They edit their country and change it from the UK to the USA. They click the save button. The page refreshes and they see.. The UK. HUH? It's been updated in the database! The problem is this: The UserRecord caches the AddressRecord into the variables scope (which is persistent because the user is in the session) when you call getAddressRecord. When you call getCountryRecord() on the AddressRecord the CountryRecord is cached too. So, let's say you update the AddressRecord and set the CountryId from 1 to 2. Wouldn't you expect the results of calling getCountryRecord() to reflect the correct record? I would! But it doesn't because the CountryRecord is cached and is not refreshed automatically when you set the countryId. I know I could have chosen to have reactor generate code that would invalidate the cached CountryRecord when the countryId was changed in the AddressRecord. However, this didn't smell right to me. It seemed to be adding complexity to the Record that's not needed. Furthermore, there were even more issues when working with Iterators. (You can only set the sort by one time! If it's cached you're hosed!) So to be consistent, at least for now, I've removed the caching and the related headaches. The other thing I've done: I've dropped the Record off the getXyzRecord method. It now will be getXyz. I know there is a lot of controversy over this. I've given this a lot of thought and I sincerely feel that this is the best approach. My logic is that you don't ask the reactorFactory for an XyzRecord, you ask it for an Xyz. IE: reactorFactor.createRecord("xyz"), not "xyzRecord". I've toyed with this in my code and it seems to feel better and smell better. This raises the question of what will happen to the iterator's naming convention. For now nothing. But, it's something I'm going to have a hard eye on. FYI - the blog and contactmanager samples have been updated. The docs HAVE NOT. Doug -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
