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
|
I have the following code: Query query = new Query(typeof(Result), Entity.Attribute("Date") >= StartDate && Entity.Attribute("Date") <= EndDate && Entity.Attribute("PerformanceIndicator") == PerformanceIndicator);return (double)UnitOfWorkHolder.Current.Calculate("SUM", "Value", query);I want to know if it's possible to then take the return double and pass it to a user defined function to manipulate? Thanks |
|
|
|
|
Officially, this isn't currently possible. However, if you don't mind seeing the scurviest and most low-down hack ever seen west of the Pecos, read on. It turns out that the way LightSpeed generates calculation SQL can be hijacked to put function calls around the result, just by adding brackets in weird places. For example, suppose we have a UDF SquareOf. Then we can modify your calculation from: Calculate("SUM", "Value", query); to Calculate("dbo.SquareOf(SUM", "Value)", query); Note in particular the right bracket after Value. LightSpeed will trustingly pass this on to the database, where the extraneous bracket will balance the bracket we generate for SUM, and will therefore of course be treated part of a function call rather than part of a column name. I can't in all conscience recommend this. It is a fortunate side-effect of the way we generate SQL rather than a by-design behaviour, and it's obviously extremely ugly and potentially error-prone. There will be circumstances in which it just doesn't work -- for example, if the identifier has to be escaped, that will probably break the fortuitous bracket matching and result in a database exception. A better approach, depending on your requirements and constraints, may be to implement a UDF that combines the existing UDF with the SUM operation (e.g. SquareOfSum), and use that as your calculation: Calculate("dbo.SquareOfSum", "Value", query); In post-2.1 builds you could also use stored procedures. In both cases, however, this requires database changes, and reduces the flexibility to use the UDF with different operators. So if neither of these solutions is viable, the kludge solution may have to do as an interim measure until we implement a proper API. |
|
|
|
|
Does Calculate is not working anymore (version 2.2.973.10596)? When I try to use Calculate I'm getting this error:
|
|
|
|
|
It should be working -- we haven't changed anything around that method. Is it possible you are using the method within a LINQ query e.g. from c in uow.Contributions where uow.Calculate(...)...? That wouldn't be supported. Otherwise, can you post the code that's giving the error please? Thanks! |
|
|
|
|
That's probably LINQ fault. Any ETA on supporting fully LINQ? |
|
|
|
|
It's a high priority for 3.0, but we can't commit definitely to a feature set or a timescale at this point. |
|
|
|
