Ayende @ Rahien

It's a girl

Challenge: Write the check in comment

In my code base, I have the following commit, which doesn’t have a checkin comment. This is the before:

private Entry GetEntryForSlug(string slug)
{
var entry = session.CreateCriteria(typeof(Entry))
.Add(Restrictions.Like("Slug", slug))
.UniqueResult<Entry>();

if(entry != null)
return entry;

//try load default document
return session.CreateCriteria(typeof (Entry))
.Add(Restrictions.Like("Slug", slug + "/default"))
.UniqueResult<Entry>();
}

And this is the after:

private Entry GetEntryForSlug(string slug)
{
var entries = session.CreateCriteria(typeof(Entry))
.Add(
Restrictions.Like("Slug", slug) ||
Restrictions.Like("Slug", slug + "/default")
)
.SetMaxResults(2)
.List<Entry>();


return entries
.OrderBy(x => x.Slug.Length)
.FirstOrDefault();
}

What was the silent committer thinking about when he made the change? Can you write the check in comment?

Comments

Dmitry
10/17/2009 08:30 PM by
Dmitry

I assume the || operator is a bug. The committer was probably thinking about a LINQ-like optimization.

Incidentally I did a very similar thing yesterday using Criteria lambda extensions. Instead of writing code like

myCriteria.Add(p => p.FirstName == fname)

              .Add<Person>(p => p.LastName== lname)

I wrote

myCriteria.Add(p => p.FirstName == fname &&

                                                  p.LastName== lname)

and it took me a minute to realize why I was getting a runtime exception.

Matt
10/17/2009 08:36 PM by
Matt

I'd guess that it was rewritten to perform a single database query instead of unnecessarily performing two.

Chris Airey
10/17/2009 09:35 PM by
Chris Airey

Maybe i'm wrong, but it doesn't like like neither of the queries are trying to archive the same result.

JBland
10/17/2009 09:42 PM by
JBland

I've been bitten by this before.

UniqueResult will throw an exception if the query returns more than 1 row, which is quite possible when using LIKE.

Mike
10/17/2009 09:54 PM by
Mike

He should use StringBuilder:

var sb = new StringBuilder().Append("slug").Append("/default") .ToString()

It would be faster.

:)

tobi
10/17/2009 10:11 PM by
tobi

why would that be faster? it would be slower.

comment: changed GetEntryForSlug to also return an entry for url with postfix "/default". first i try to find an entry that is an exact match for the slug. next i try it with a postfix. i ensured this by ordering by the length of the returned result list because the entry without postfix will be shorter and therefore first."

Steve Py
10/18/2009 07:08 AM by
Steve Py

I get what the re-factor is doing, though I can't say I agree with it. The original code is pretty clear exactly what it's doing. return the item, if not found return the default, if not found, return #null. If anything, my only concern might be that the code is doing more than "one thing." For instance it might be a bit of a nuisance after the fact to determine if you actually retrieved an item or ended up with a default. But that's a digress.

The re-factor reduces the potential 2 queries to 1, however I'd say the readability of the intention of the code suffers. Get a list of the item an/or the item's default, then return the shortest one; assumed to be the item, if found, else the default, if found, else #null.

The thing is it took a couple careful passes looking at that to be sure it didn't have a "gotcha" or difference in behaviour. Frankly I favor readability over sheer optimization unless performance is a significant issue. Even so, in the ideal case where the "real" item is found, the extra query condition and LINQ sort & extraction is itself imparting an extra performance cost. I doubt the gain on average is more than negligible if anything at all.

Not sure what the actual choice in GIT comment ended up being, but I'd suggest that the following one should be an "Undo". ;)

Nick Aceves
10/18/2009 10:48 AM by
Nick Aceves

@Steve,

While the code could certainly be more clear, it would be naive to suggest that the performance improvement is negligible. Surely you're not suggesting that an extra filter condition and a Linq OrderBy cost more than another round trip to the database...

To me, it really depends on how often we expect this code to load a default entry. If we are going to find real entry 90% of the time, I'd say leave the code as it was. If, instead, we're expecting to need a default entry around 50% of the time, and this code gets called frequently, then some kind of query optimization might make sense.

Phillip
10/18/2009 12:09 PM by
Phillip

I don't know what this is from or for, but could it not have been written like:

private Entry GetEntryForSlug(string slug)

{

return session.CreateCriteria(typeof(Entry))

    .Add(

        Restrictions.Like("Slug", slug) ||

        Restrictions.Like("Slug", slug + "/default")

     )

    .OrderBy(x => x.Slug.Length)

    .FirstOrDefault();

}

If so then that's far more read-able than both the original and committed... And it's not retrieving the result before deciding what to do with it...

Phillip
10/18/2009 12:13 PM by
Phillip

Actually I just realized why the result was retrieved first, so that the orderby/firstordefault could be used against the resulted list...

Forget what I said I'm an idiot :)

Steve Py
10/18/2009 11:34 PM by
Steve Py

@ Nick,

It's an assumption either way. Based on that type of behaviour and where that method would likely be called, my guess would be it would be expecting to find the real one at least 50% of the time. The higher the percentage, the less effective that optimization becomes, and at some point it becomes an averaged penalty.

Still, my main point was that the re-factor hurt readability, and unless the gain was significant (i.e. noticable to the end user) then it wasn't worth it.

neonp
10/19/2009 07:36 AM by
neonp

So obvious when working with ORMs :

Improved performance from 2 queries to one.

Will Smith
10/19/2009 03:53 PM by
Will Smith

I wouldn't call this a "refactoring" as there is a clear change in behavior. This is a rewrite (on a small scale). A refactoring is "restructuring an existing body of code, altering its internal structure without changing its external behavior." as defined by Martin Fowler.

I would assume that said developer has a valid reason for this performance rewrite. neonp's "comment" seems the be the most accurate and concise.

Ayende Rahien
10/19/2009 03:59 PM by
Ayende Rahien

Will,

What is the external behavior that was changed?

Will Smith
10/19/2009 06:40 PM by
Will Smith

I knew that question would come up. Perhaps it's a stretch, but, I would say performance is the observable change in behavior here.

To me refactoring follows prescribed methods of modifying the structure of the code and has no effect on the algorithms in place. In the case above it seems the algorithm has been changed to observe improved performance.

I don't know, maybe Martin would ask what I've been smoking.

Patrik H&#228;gne
10/29/2009 07:45 PM by
Patrik Hägne

@Mike: I'm not sure you're serious, but I know for sure that there are a lot of developers out there that actually believe that to be true. The matter of fact is that in simple concatenation cases like this using a StringBuilder would be orders of magnitude slower.

Tom Marien
10/30/2009 08:58 AM by
Tom Marien

Comment : Did not slept well this night therefore i thought how i can screw up a working system.

The GetEntryForSlug now can return null, instead of throwing an exception when nothing matched (before uniqueresult, now firstordefault)

Kind regards

Ayende Rahien
10/30/2009 12:00 PM by
Ayende Rahien

Tom,

UniqueResult will return null if nothing is matched

Tom Marien
10/30/2009 12:24 PM by
Tom Marien

I guess the comment counts for me then :P

Comments have been closed on this topic.