LightSpeed Query API

Hi,

Currently I'm using LS 3.0. The following LINQ query works well:

            var policyPremiums = from pp in UnitOfWork.PolicyPremia
                                 join pc in UnitOfWork.PlanCodes on pp.PlanCodeId equals pc.Id
                                 join pa in UnitOfWork.PlanAssignments on pc.Id equals pa.PlanCodeId
                                 where (pp.GenderTypeId == genderTypeId) && (pp.IssueAge == issueAge) && (pa.PolicyTypeId == (int)policyType) && (pa.StateId == stateId)
                                 select pp;

However, what is the equivalent query using the LS Query API? I cannot get the proper structure worked out using Join.Inner / .And.

With respect to performance, how does the LINQ implementation compare with Query API?

It would translate to something like this:

var query = new Query()

{

  EntityType = typeof(PolicyPremium),

  QueryExpression = Entity.Attribute<PolicyPremium>("GenderTypeId") == genderTypeId && Entity.Attribute<PolicyPremium>("IssueAge") == issueAge && Entity.Attribute<PlanAssignment>("PolicyTypeId") == (int)policyType && Entity.Attribute<PlanAssignment>("StateId") == stateId

};

query.Join = Join.Inner<PolicyPremium, PlanCode>("PlanCodeId", "Id");

query.Join = query.Join.And(Join.Inner<PlanCode, PlanAssignment>("Id", "PlanCodeId"));

var results = UnitOfWork.Find(query, query.Mappings);

var policyPremiums = results.GetCollection<PolicyPremium>().ToList();

You probably would like to write the query.Join as a single statement using firstJoin.And(secondJoin), so I have added a small addition into tonights nightly build (20100122) to more nicely support that due to the way it currently handles mapping the internal query aliasing which currently requires you to assign each join in turn.

In terms of performance, the LINQ provider always performs a translation to a Query object and then executes that and then may perform some client side operations depending on the nature of the query, so using the native querying API will always be slightly faster for any given query because you are removing the overhead of parsing the LINQ expression tree.

Jeremy

Perfect. This is very helpful!