Christopher Browne <[EMAIL PROTECTED]> writes:
> It sounds like the world "needs" some form of "transaction filter."
Yes.
> That is, a mechanism whereby you walk through a set of transactions,
> with a function that evaluates the contents of each transaction,
> transforming it into another transaction as needed.
Maybe. The Query API was designed to do exactly the first part of
this problem: walk over the transactions, using the most efficient
means available given the backend, and select a set of transactions
based on a (possibly quite complex) criterion.
I think the Right Way to solve this problem is to use the Query API to
select a set of transactions, *then* apply the transformation to all
splits in the set.
The wrong way to do this is to build a transformation system that
depends on manually examining every split. We really want to make
this scalable to a multiuser (i.e. SQL backend) scenario where
possible; the Query API will let you do that, but if you explicitly
start iterating over all splits in your user code you will be cooked
on an SQL backend.
b.g.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
