Few days back Manju logged a bug in CF-ORM saying ‘lazy’ does not work for many-to-one relation and that too on non-Windows machine. At first, I simply rejected the bug because a) ORM can not have anything to do with OS and therefore, if it works on Windows, it works on all the plaform and b) I know it works
. But he did not agree and I had to take a look at that machine. And apparently he was right – lazy was not working ! The related entity was in-fact getting loaded immediately. (Question for you – how will you know that lazy is working or not?)
Even after seeing this, I did not believe it and asked him to replicate this on another system and he successfully showed that to me on one another system. And he agreed that it works fine on most of the configurations. The problem exists only on a few of the systems.
This got me thinking – Why would a relation get loaded immediately even after it is marked lazy? The only answer would be – if some one is accessing that lazy field and calling some method on it. I checked his code which was loading the entities to see if there could be any case, where the field would get loaded and unfortunately there was none.
And then suddenly it hit me – what if “memory tracking” is swithched on? That would access each of the field of each object recursively to compute the size of an object and that can definitely cause this. I immediately checked the server monitor and the “memory tracking” was right there staring at me in “red”! It was indeed enabled. I asked Manju to check the other system as well (where lazy was not working) and the memory tracking was enabled there as well.
So the lesson – If the ‘memory tracking’ is enabled on the server, the relationship will no longer remain lazy. And btw, you should enable “Memory tracking” on the server only if you need to track the memory for some troubleshooting. Memory tracking is really really expensive in terms of performance.
Another reason why it might not work for you could be – if you are sending the object to flex. Currently, during serialization, the related objects also get sent irrespective of the lazy attribute set on the relationship. We are still working on it and hopefully by the time we release, this will be fixed.

#1 by Devin on July 31st, 2009
| Quote
Question for you – how will you know that lazy is working or not?
Can’t say that I have an answer, but I’d love to know! Would it involve reading the logged SQL to see what data was queried? Seems like any available CFML code to “look” at the object (such as cfdump) ’causes the lazy data to be loaded before you have the chance to look at it.
So I guess I’ve just always trusted that the data was actually lazy. But after reading your entry I can see how it would be important to double check things like that.
So what’s the answer?
#2 by Rupesh Kumar on July 31st, 2009
| Quote
@Devin,
That is one way. You can read the logged sql and see if the sql to load the lazy objects are being called. But thats not such a nice way.
Another way is to use the event handler – You can enable the event handler and write the preLoad methods in the related class. When you just load the object without accessing the lazy properties, if the preLoad() method gets called for the related objects, it would mean that the related object is getting loaded immediately and lazy is not working.
#3 by Devin on July 31st, 2009
| Quote
Figured there was a much more simple way that I couldn’ think of. Thanks for the tip!
#4 by Hemant Khandelwal on August 2nd, 2009
| Quote
“Another way is to use the event handler”
I guess you have another idea for a blog entry
#5 by viagra on August 9th, 2009
| Quote
gratefulness you for your dope and it helped me in preparing my college assignment.
#6 by CauffFlalmTof on August 18th, 2009
| Quote
yeh right.. great post, Thank You
#7 by ontohyposaush on November 25th, 2009
| Quote
Tender thanks you championing details. It helped me in my mission