Hi

Quick question regarding the Linq builds.

Say you have an attribute on on of the entities which returns a PredicateExpression / RelationPredicateBucket

class User
{
    public RelationPredicateBucket HasOrders
    {
        get
        {
            RelationPredicateBucket bucket = new RelationPredicateBucket();
            bucket.Relations.Add(UserEntity.Relations.OrderEntityUsingUserID);
            bucket.PredicateExpression.Add(new AggregateSetPredicate(UserEntity.MemberNames.Orders, AggregateSetFunction.Count, OrderFields.ID, ComparisonOperator.GreaterThan, 0, null));
return bucket;
        }
    }
}

Is there any way to incorporate this in a linq query?

using (DataAccessAdapter adapter = new DataAccessAdapter())
    {
        var metaData = new LinqMetaData(adapter).Users;
        var results = metaData.Where(u => u.HasOrders).ToList();
    }

We had these methods on our list of code to add, but it becomes problematic: the predicates have no aliases defined for targets, however everything in a linq query gets an alias.

So even though you can pass in the predicates, it's not doable to assign the right aliases to these predicates (ObjectAlias).

So is it completely unusable / undoable or does it work in some circumstances / or is there workarounds / something similar ?

Thanks Garrett

garrett wrote:

So is it completely unusable / undoable or does it work in some circumstances / or is there workarounds / something similar ?

Thanks Garrett

In general: this is undoable. The elements in the expression tree get new aliases assigned to them and it's key these are used everywhere. When you insert a predicate expression from outside, you get things like:

... FROM Customers LPLA_1 WHERE [Northwind].[dbo].[Customers].[Country]=@country1

and this of course doesn't work.

It's also not doable to re-alias things, as this goes wrong when an entity is used multiple times. And we don't add code which 'sometimes' works, as that always breaks down in the situations where it's not acceptable that it fails (read: in production on a sunday morning at 3am )

But don't worry that this code is useless, because it's not: our query api will keep on working and we'll keep on supporting it, simply because our linq stuff is build on top of it So you can keep on using this code you wrote using normal llblgen pro code, and if it's possible to write a linq query you can, but you don't have to.

Thanks for the explanation!