1

Trying to decorate an IQueryOver by using some conditional logic. Consider the following code which is a private method on an object representing a customer search.

    private void addCustomerCriterion<T>(IQueryOver<T, T> query) where T : Customer
    {
        if (!string.IsNullOrEmpty(Name))
            query = query
                .Where(x => x.FirstName.ToUpper().Contains(Name.ToUpper()) ||
                            x.LastName.ToUpper().Contains(Name.ToUpper()));

        if (HasOpenTicket.HasValue)
            query = query
                .Inner.JoinQueryOver<ServiceTicket>(c => c.ServiceTickets)
                .Where(t => t.StatusName == "Open")
        }

        if (HasOpenInvoice.HasValue)
            query = query
                .Inner.JoinQueryOver<Invoice>(c => c.Invoices)
                .Where(i => i.StatusName == "Open");
    }

Unfortunately, this doesn't compile. Makes sense, because in the second and third if-statement, I am breaking the fluent interface's type safety. According to http://nhforge.org/blogs/nhibernate/archive/2009/12/17/queryover-in-nh-3-0.aspx, the JoinQueryOver converts my query from QueryOver(of Customer, Customer) to a QueryOver(of Customer, ServiceTicket). Types don't match up now when I try to decorate using the query = query idiom.

So the real problem here is that I've traversed down into the ServiceTicket relationship from the Customer object, and it's changed the type of my QueryOver object. How can I traverse back up the tree so that I can keep adding inner joins to the original root Customer object?

Joshua Ramirez
  • 422
  • 3
  • 10
  • did you ever find a solution to this problem? I am running into the same thing. – Vadim Rybak Jan 21 '13 at 16:06
  • No, I changed a design principle higher up in my architecture in order to reduce the complexity at this layer. That ended up making this need disappear. I'd recommend you do the same. I don't think this is the tool for what you want. Truly seeing the power of the Query Objects pattern require a more robust implementation than what is provided. – Joshua Ramirez Apr 16 '13 at 18:15

1 Answers1

2

I think the original IQueryOver you have is mutable and registers the call to JoinQueryOver so you shouldn't need to store the return value (unless you need to add more conditional joins from the joined entity).

Yhrn
  • 1,063
  • 7
  • 16