|
FYI – I committed these
changes. However, since committing them I reneged and re-enabled the
record caching. When you call getXyz the XyzRecord object is again cached
in the object. However, if you call setXyzId() it will intelligently reset the XyzRecord.
(this update has been committed) The reason I decided to change my approach
(again) is because of the following example. Without caching anything,
how many queries would have been run? (Not including loading the User)
<cfoutput> #User.getAddress().getStreet()#<br> #User.getAddress().getCity()# #User.getAddress().getStateProv().getName()# #User.getAddress().getPostalCode()# #User.getAddress().getCountry().getName()# </cfoutput> Answer: 7!! 5 times for getAddress()
and 1 time for getStateProv() and getCountry() By re-enabling caching that 7 can be
brought down to 3. I’m not much of a fan of the fact that
getStateProv and getCountry run a query… but at least once they’re run
they’re cached! And it’s not that much data anyhow. It
feels acceptable. The big problem I see now is this code: <cfset User = reactor.createRecord(“User”)
/> <cfset User.setFirstName(“Doug”)
/> <cfset User.getAddress().setStreet(“ <!--- assume the rest of the props are
set for both the user and address ---> <cfset User.save() /> It feels like this should save the address
too. (I’m working on this.) Furthermore, what if the user and
address are both new? The address needs to be saved first and it’s
addressId needs to be set into the user’s addressId before the user is
saved. Or what about this: <cfset User.getAddress().delete() /> What happens in the user?! I’ve
got no clue. Maybe I could automate the process of adding event handlers
so that the User could listen for certain events on the address and could catch
that the address was deleted and set its own addressId to 0 and remove its
reference to the address. (Right now the User.getAddressId() would be n
while the Address.getAddressId() would be 0). Or maybe the delete method doesn’t
DO anything until later? IE maybe I can delete it, but I have to call
commit to delete it? I suppose that’s still the same problem. There’re a lot of big what-ifs when
you start messing around in this stuff. Any feedback would be wonderful. Doug From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes 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 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 CF] Imporant changes commng to reactor this we... Doug Hughes
- RE: [Reactor For CF] Imporant changes commng to reacto... Doug Hughes
- Re: [Reactor For CF] Imporant changes commng to re... Chris Phillips
- Re: [Reactor For CF] Imporant changes commng to re... Kurt Wiersma
- Re: [Reactor For CF] Imporant changes commng to reacto... lists
