changing a large number of transactions in a batch -- impossible?

[Anna's unattended mail]

On 2012-08-20, Derek Atkins <warlord at MIT.EDU> wrote:
>
> That begs the question of how you got hundreds or thousands of
> transactions input with the wrong data in the first place?

It doesn't matter how it got that way.  

> Perhaps the right time to fix it would be when you enter the data?

This would require a crystal ball.  Users cannot predict the future.
This is like saying an OS does not need a "mv" command, because users
can organize their files in advance, and put each file in the right
place the first time.

If you cannot make changes, scalability is shot.

>> Suppose your business books are mixed with your personal books, and
>
> This is already a bad idea....

Depends.  If a business only needs one asset, income, and expense
account, breaking it into two files only creates inconvenience.  It's
also safer in the sense that it's easier to have one file that needs
to split than it is to have two files that need to merge.

Same with currencies.  You can create a new top-level expense account
for each currency, or you can keep the same tree and create a new
leaf-node account for each currency, or you can create another whole
book (file) for each currency.

Each approach has different merits, and a user might only know they
made the wrong decision 1000+ transactions later.

> Not necessarily any easier.

I'm not sure how XML could be easier to hack than sql.  XML would
require a special parser (which in effect builds a database
internally), and there would need to be a DOM parser API for each
language that users would need to work in.  SQL is a universal
language that would be all a user needs to know for most things.  Plus
there are SQL APIs for all the high-level languages, if someone needs
to do something more complex than pure SQL.

> We don't have a good test suite to make sure every API actually
> works with every backend.

Why would GC developers support more than one API?  They should only
have the burdon of supporting the sql API that gnucash itself uses.
If someone wants to use another toolchain, it would be their
responsibility to make necessary changes.  As long as the test suite
covers the GC-SQL API, that would prevent disruptions to regular
users.