This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
hi, re this thread (sorry!): http://www.mindscapehq.com/forums/Thread.aspx?ThreadID=2653&PageIndex=2 I've implemented the same, based off owen's code. It's working except that the associationresolver is not firing at all - and so the query constraint includes only the ItemId, not the OrgId. so my question is this - could you just verify how the associationresolver should be setup so that it is picked up by LS when resolving the association? I'm running on a nightly build from 2 days ago. will send you the two classes in question via email to support email. i'm sure it's just a stupid mistake somewhere in the setup but i can't spot it. cheers! justin |
|
|
|
|
No mistake -- I'm afraid you have hit one of the "limitations and restrictions on the use of custom resolvers" mentioned in the docs. The problem is that custom resolvers aren't supported in an Exists clause (and therefore in the LINQ Any or All operator). This is because IAssociationResolver.GetQueryExpression only allows you to return the query expression for traversing a particular instance of the association -- because GetQueryExpression takes an entity as an argument -- whereas constructing an Exists clause requires an abstract expression of the relationship between entity types. Unfortunately, extending custom resolver support to Exists clauses isn't likely to be a quick fix. It may be possible to reformulate your query to avoid the association traversal; failing that, you may need to resort to FindBySql or a stored procedure. |
|
|
|
