Resulting in much premature baldness :-)

We are currently in beta and will be releasing in the next couple of weeks. For now you could link to: http://www.mindscape.co.nz/blog/?p=23 and we also have an EAP site: http://eap.mindscape.net.nz/

Cheers,

Andrew.

/Mats

Interesting!

And while it looked at a glance like using subselects could be easier, I discussed it a bit with Roger Johansson and it quickly became apparent that it probably is much harder, yes.

/Mats

Good question! The reason for the subselect is because it better represents my intent: Give me *only* OrderLines that have Orders from a Customer whose Id > 0.

See: http://andrewpeters.net/2006/09/28/quote-of-the-day-from-oracles-ask-tom/ for a bit more info.

As discussed in that post, I’m relying on the DB optimizer to figure things out. If it turns out that a join based strategy is consistently faster then I will need to review the implementation. With respect to it requiring less-transformation, an early iteration of the query builder used a join strategy and I seem to recall it was easier to implement.

Cheers,

Andrew.

“Named aggregates are not essential for this”,

The part that would be essential (I think) is to be able to tell the mapper when it will be alright to resolve both sides of the relationships it touches when filling the objects. I think that stating “My query is againist a named aggregate” in the query, and letting the mapper provide the secondary sql statements from that information, provides exactly the information I was looking for.

In your new sql example to Kirk,

Why do you use a subselect in the third statement instead of just a join (in the where clause! we’re not talking about joining in tables into the result, getting Cartesian products)? Is it because it requires less transformation (you can basically just wrap the original query up into the subquery) ?

/Mats

Good spotting. If no criteria have been set and we are eagerly following a dependent association (fk not null), then we can omit the filtering normally required to return the right set of child objects.

So, for the more common case:

// contrived example:
 
Repository.Find<Customer>(Entity.Attribute("Id") > 0)

We end up with:

SELECT
  Customers.Id,
  Customers.CustomerName
FROM
  Customers
WHERE
  Customers.Id > 0;
 
SELECT
  Orders.Id,
  Orders.IsShipped,
  Orders.CustomerId
FROM
  Orders
WHERE
  Orders.CustomerId > 0;
 
SELECT
  OrderLines.Id,
  OrderLines.Total,
  OrderLines.OrderId
FROM
  OrderLines
WHERE
  EXISTS (
    SELECT
      Orders.*
    FROM
      Orders
    WHERE
      Orders.Id = OrderLines.OrderId AND
      EXISTS (
        SELECT
          Customers.*
        FROM
          Customers
        WHERE
          Customers.Id = Orders.CustomerId AND
          Customers.Id > 0
      )
  )

Still single batch, 3 selects however.

Cheers,

Andrew.

Thanks!

Named aggregates are not essential for this just the EagerLoad attribute. Named aggregates simply allow for varying eager/lazy behavior at the association level per use case.

Cheers,

Andrew.

The information that I wanted to put in a new type of DSL in my posts about Eager Loading “Hints” is neatly contained in your named aggregates! Completely brilliant and /exactly/ the type of good thinking about the problem that I was looking for!

So, you indeed pass the challenge, and your answer to the problem behind the challenge is named aggregates. My hat is well and truely off!

/Mats

Does that mean that you’ve specifically coded for the unfiltered case — where if the root collection is filled with a “select *”, you determine that the eager fetching is also a “select *” based upon the relationship type?

Not often that want to load a whole tree of the database into memory, but when I do, I guess it pays to be as efficient as possible.

Cool.

Kirk