Nhibernate/ActiveRecord Lazy Loading Fails when Ignore is Set

Recently our [BelongsTo] relationships in ActiveRecord with the Lazy = FetchWhen.OnInvoke have stopped lazy loading. This caused some massive performance problems. Suddenly entities that were not supposed to be loading unless invoked were loading all of the time.  I've been struggling with this for a couple days and just now found the answer.

Here is the property definition in question:



Normally, when retrieving an instance of "SomeEntity" the HomePage property would not load until it was accessed by some code. Two days ago, using the Nhibernate Profiler, I noticed that HomePage was being loaded...all of the time.

I tried so many possible solutions and searched for a possible answer until I came across this article.

It turns out that when you set NotFoundBehaviour=NotFoundBehaviour.Ignore on a BelongsTo relationship it circumvents the lazy loading and loads the entity anyway. I also found a bug that has been posted for this as well. Although the link rarely works well.

Death March Values...revisited

Some time ago, I was reading a great page on the C2 Project Wiki about Death March Values. This is in no way implying that we have this problem here...but these are habits we should not fall into.

The basic concept is that some organizations have a subculture that continues to employ self-destructive values over and over again. Here are a few indicators that you may be in one of these organizations:

•  Business Value Desicion Makers (BVDMs) want the "magic" of software without considering the work involved, "ProductWithoutProcess".
•  BVDMs reward the guy who stayed up all night fixing a bug while the guy/gal who's code always works the first time gets little recognition. The Hero Programmer
• Young Hotshot Programmers fall in love with a product "Project Love Affair", take little time to consider the broader picture and fail to employ the Practices.

In most organizations you can insulate against the Death March Values by not accepting the status quo. In some organizations it's so embedded in the culture that you may never be able to fight the tide.

Here are several things your development team can do to mitigate the Death March Values:

• Commit to only as much work as you can do
  This is tough because most teams don't know how much work they can get done. Always track the amount of work you have done in the past so you can properly estimate in the future.
  
• Set a schedule and stick to it
  Sticking to a schedule is tough, but if you only commit to as much work as you can perform then you won't have a problem. The two things that will affect your schedule the most are distracting task and scope creep.
• Value working software over scope creep
  Inevitably, near the end of a release everyone wants to pile on "just one more feature." In these moments you must remind everyone that it's more important to get the bulk of the new features out to production rather than "creep" in new ones.
• Accept success and failure as a team
  Simple...enough said ;-)

 See also: Death March Project

Top 12 Things Likely To Be Said By A Klingon Programmer

found originally at  Courtney Hentz (CHentz@spinner.com)

1. Specifications are for the weak and timid!
   
2. This machine is a piece of GAGH! I need quad PowerPC processors if I am to do battle with this code!
   
3. You cannot really appreciate Dilbert unless you've read it in the original Klingon.
   
4. Indentation?! I will show you how to indent when I indent your skull!
   
5. What is this talk of `release'? Klingons do not make software `releases'. Our software `escapes' leaving a bloody trail of designers and quality assurance people in its wake.
   
6. Klingon function calls do not have `parameters' - they have`arguments' - and they ALWAYS WIN THEM.
   
7. Debugging? Klingons do not debug. Our software does not coddle the weak.
   
8. I have challenged the entire quality assurance team to a Bat-Leth contest. They will not concern us again.
   
9. A TRUE Klingon Warrior does not comment his code!
   
10. By filing this bug you have challenged the honor of my family. Prepare to die!
    
11. You question the worthiness of my code? I should kill you where you stand!
    
12. Our users will know fear and cower before our software! Ship it!Ship it and let them flee like the dogs they are!
    

Documentation Specialists

*** UPDATE Dec 20, 2010, We ended up using the tool MadCap Flare. I'll post some pros and cons later ***
So, we just hired a new documentation specialist. We're looking at a tool named Help Studio. If anyone has any suggestions please let me know.


I intend to treat her as any other developer (a pig). Currently our workflow is: Engineer Resolves Case to QA and QA Closes case. The new workflow that we will try out is: Engineer resolves case to Documentation, who then resolves to QA, who then closes.

Over the next couple of weeks I will write more about how things work out.

From SVN to Mercurial: Part 1

Recently, we have begun dividing our work amongst several teams on different branches. This prompted us to start moving from Subversion (SVN) to Mercurial.

We have actually had great success with Subversion (SVN). We moved from CVS several years ago and have never regretted it. With it's improved rename and move support and cleaner branching SVN was an easy decision.

Now we find ourselves, once again, pinning for the capabilities of a Version Control System that we don't have. We are also in the throws of moving build servers from Luntbuild to Hudson. So, over the next few posts I'll discuss our experiences with moving from SVN to Mercurial.