Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> Personally, I think that this is one weakness in the present
> approach to report generation. I would prefer to see an
> implementation that does the calculations in the engine (as directed
> by the report generator) and only does the displaying in the
> external part. That way we would be able to take advantage of
> database implementations of the summation in the case that we use an
> SQL database for the store.
But until we have a better idea of what our data type's going to look
like, I'm not sure we can accurately evaluate the kind of computations
we're likely to be able to push into an SQL back end. For example, I
suspect if we go with something like a rational number library that
choice will have very different implications for what *can* be done in
the back end as compared to going with a fixed point library.
In fact, this might be an important point to consider when specifying
our new data-type/api if we really believe we're going to stick in an
SQL backend eventually, and it seems like there's a substantial case
to be made for that.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
