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.

Reduce number of potential queries by 50 %

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

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

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.

He should use StringBuilder:

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

It would be faster.

:)

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."

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". ;)

@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.

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...

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 :)

@ 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.

So obvious when working with ORMs :

Improved performance from 2 queries to one.

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.

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.

My logic may be slightly flawed, but it appears Martin and I are in agreement (well at least back in 2004)

martinfowler.com/.../...timizationRefactoring.html

@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.

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

I guess the comment counts for me then :P