Jacopo,
In that case it shouldn't be a big deal performance-wise to do the
calculation in a simple-method or Java service based on a database
query, rather than putting the formula in the query itself.
-David
On Dec 19, 2006, at 10:51 PM, Jacopo Cappellato wrote:
David,
the idea was to 'implement' that sql statement within a service
(and a view entity definition) and run it (probably as a seca)
every time a product is received/shipped/etc... (i.e. everytime the
qoh of a product changes); the result of the service call could be
stored in the ProductAverageCost entity.
So it will run many times a day but for just one Product/Facility/
OwnerParty at a time.
Now we have two choices I guess:
1) improve the complex-alias stuff to support the sql statement
2) implement it in a different way (e.g. in a Java based service)
Thanks for your help,
Jacopo
David E Jones wrote:
Jacopo,
This is a good question, and something that the entity engine
isn't really all that well suited for.
Are you trying to calculate this for a single Product/Facility/
OwnerParty or a small group of them, or is it something that you
intend to have run globally and possible calculate many many of them?
One thing about this sort of calculation is that it may change
over time or involve other factors and such. In other words, it
would be nice to have this logic implemented with the rest of the
logic in the service tier on the application server. Of course,
that wouldn't work so well if this is meant to calculate a large
set of these, like hundreds of thousands for example (it could
work, but it would just take a much longer time to execute).
The closest thing to this that exits in the entity engine is the
complex-alias stuff that is part of a view entity, but that does
not currently support a combination of functions and math
operations, it just supports math operations for now. It is
hierarchical however, so if it was extended we might be able to
reasonably do this...
-David
