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

[Derek Atkins]

"Anna's unattended mail" <anna.morris-1okt59qe at cool.fr.nf> writes:

>> 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

XML can be opened in any text editor and modified there.

> 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

Nah, no need to be that complicated.  Just M-x replace-string to change
the guids.  But it's dangerous to do that.  It's also dangerous to do it
in raw SQL.

> there are SQL APIs for all the high-level languages, if someone needs
> to do something more complex than pure SQL.

There's also the Python GnuCash bindings which would let you do it
programatically and safely.

>> 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.

Sorry, let me be more explicit here, because you and I are using the
word "API" to mean different things in this context, so let me rephrase.
GnuCash does not have a good test suite that tests every function within
the GnuCash C API against every backend to make sure that each function
(and set of functions that are designed to work together) works properly
with every backend.

There is no "GC-SQL API" per se.  There is a "GNC Backend API", but
that's not sufficient to prevent data loss because there are definitely
ways to use the GnuCash Engine in a way that will cause data loss.  The
reason is that GnuCash is NOT a DB App.  It never was.  The DB Backend
is purely a data store that happens to use a SQL DB as the data store
instead of the XML File.  But it's still just that, a Data Store.  There
are still places in GnuCash that make the assumption that GnuCash will
write out the whole dataset via "Save".  And those are the data-loss
places we need to find.  It's also in places we don't have tests.

So no, until we get a comprehensive test suite over the entire GnuCash
Engine API and apply it to every Backend, alas, no, we cannot be assured
that we wont have data loss.

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available