XML size (was: no subject)

Derek Atkins warlord@MIT.EDU
03 Apr 2002 09:36:22 -0500

Roland Roberts <roland@astrofoto.org> writes:

> I'm a lurker here, but I'll jump in anyway.

Please.  Comments are welcome...

> As a user, I would see little or no benefit in having the internals
> changed to using embedded SQL if externally it is still a file.  The
> benefit to me is when I can have both my wife and I work on gnucash
> simultaneously.  Most often we both want to update our accounts once
> the kids have gone to sleep.  Having a file requires we do the updates
> sequentially even though the updates are orthogonal.  Having a *real*
> database gives me features a file doesn't.

One reason to do it this way is to make it easier to move from an
embedded SQL to a real multiuser SQL.  Obviously you want the latter,
and actually it exists currently in CVS.  This means that you can
safely ignore this thread, because it wont affect you.

Also, just because the database is a file does not mean that two
applications can't access it simultaneously.  Granted, that depends on
the database implementation.  However, in most of these
implementations the file is accessed in real-time during querries, and
changes are written out in real-time.  So, theoretetically you could
have multiple applications attached to the same file, provided they
don't cache responses (which, unfortunately, gnucash does).

> No, I'm not an average user in that I already have PostgreSQL set up
> for other things, and I don't consider the extra work to be a burden.
> But your average person probably will which means that the change to
> use SQL internally is only useful to me if it can switch been "file"
> and database server.

As you said, you are not an average user.  You would already use the
(existing) postgres backend, which I do not propose to change or

One of the interesting benefits of MySQL (according to their
documentation) is that you can write an application based around
MySQLD (the embedded SQL server), but link it against a stub library
and run against the normal, multiuser MySQL server daemon, without
changing your application.  Is this what you were worried about?

> roland


PS: again, I am not arguing for changing the existing SQL/Postgres
       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@MIT.EDU                        PGP key available