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
|
Details as per comments here http://www.mindscapehq.com/blog/index.php/2010/09/14/ninja-domain-properties-in-lightspeed/ Basically, LightSpeed's really cool expression feature breaks when the properties are properties of interfaces. But, properties of interfaces are the main time I'd like to use them :-) |
|
|
Thanks John, Are you able to fire through the repro you mentioned? As you have surmised this isnt really supported in its current form but I would be interested in how you are looking to use it to see what we need to change/add in as this would be quite a useful addition.
|
|
|
Sure. Please find repro attached. The basic idea is that
Hope that makes sense, and is illustrated by the attached sample. Let me know where further clarification may be required... Regards, John |
|
|
Hi John, Thanks for the repro! Much appreciated - certainly helped clarify what you are after. For your second test the reason this is failing is because you have not marked the fields as static (which is required for them to be picked up). I have had a think about the way the implementation around the 3rd test is set up but unfortunately I dont really think this is going to be something I can change (for now). The way we currently handle this feature is to look for a field on the implementing type (as described in the blog post). This is done as we are parsing the LINQ expression tree and building up the criteria so that it can be appended to the Query object which will later be used to execute the query. When this process runs the only context it has is the details of the MemberInfo it is extracting which in the case of a property on an interface means we only know about the interface and not about which type it may ultimately be used with. Because we need to understand exactly what to translate it to at that point in time (which would be open to interpretation by the implementing types) this means we dont have the right information to work with to make that translation. In order to make this happen we would need to have more context about the types involved in the query at the point where we make this translation (or to defer that translation to later where we would have that information available) but either of these changes would require a fair amount of work within the LINQ provider to make that happen. So unfortunately for now Im going to have to put this one on the backlog as a future enhancement.
|
|
|
Hi Jeremy, Thanks for looking into it, and for posting the detailed reply. I thought something was wrong with that second test, because I'd had something similar work previously, but didn't spot the missing static. As for the third test, given your explaination I can see why it has to wait for another day :-) Thanks for looking into it. John |
|