sqlite file format, anyone?

[Christopher Browne]

Derek Atkins wrote:
> Christopher Browne <gnucash at cbbrowne.com> writes:
> 
> > It seems no more reasonable to expect that casual home users have to:
> > 
> >  - Run mke2fs, or whatever else is involved in setting up filesystems;
> >  - Run whatever frightening incantations are involved in getting X
> >    working.
> 
> If this is how you feel then you are grossly over-estimating the
> competence and skillset of the average user.  Most users grab the Red
> Hat install media and click "go".  They have no clue what mke2fs is.
> They have no clue how to set up X.

It nonetheless happens, does it not?  They _do_ have to cope with it, in
some manner, because X and ext2 don't get there by magic.

Reciting some mantra of "embedded database, embedded database" will also
not lead to the system being simpler just because it gets repeated
enough times.

>> And the notion that PostgreSQL doesn't have an "embedded server" is
>> just not true, unless you're hung up on trying to force there to be
>> just one OS process.
> 
> Indeed, I am.  Another process means another thing to crash, and
> another service to operate.  My parents can barely login to their
> computer, let alone administer a postgres DB.  Also, I come from an
> environment where people don't own their machines.  They use public
> cluster machines with a distributed file system.  The average user
> cannot start any process that needs root access; all processes are
> owned by them.  Starting a postgres server in this environment
> is... challenging.  However an embedded server would work just fine,
> because is runs within the application in the user's context.

I never said "root."  The whole point of the following recipe is to
demonstrate that root access is _unnecessary_.  

- None of the following involves starting any process that needs root
  access.

- All processes are owned by _the user_.

- Starting the postgres server, in such an environment, is _not_
  challenging.

> > mkdir("~/GnuCash/DB");
> > system("initdb -d ~/GnuCash/DB");
> > [dribble a few changes into ~/GnuCash/DB/{pg_hba|postgres}.conf,
> >    notably turning on TCP/IP, picking a port #, probably not too 
> >    much else...]
> > system("pg_ctl -D ~/GnuCash/DB start");
> 
> Well, this isn't very portable.

Well, it requires:
 a) Figuring out the path to the PG tools, and
 b) Deciding a path to where the data goes.

Certainly there's a _little_ more to it:

- The appropriate program paths need to be determined.

- Wrapping this for "production" use to have error checking and to allow
  the Advanced User to choose to use a pre-existing database would
  certainly require more code.

- You'd want for GnuCash to shut down the "embedded" server, if it was
  being controlled by GnuCash.

- You'd want to set up a similar wrapper to dump out the data to a
  single file to support doing backups.

- Error checking is needed.

But none of that changes the vital points, that
 - The "embedded" process belongs to the user;
 - So do the files;
 - It does NOT forcibly require a sysadmin's attentions.

> > That may require having multiple processes around, but I absolutely
> > reject that this represents any sort of "problem" worthy of "solving."
> > Linux is a Unix-like system, and does a perfectly good job of managing
> > any reasonable number of concurrent processes, and even quite
> > _un_reasonable numbers thereof.
> 
> Well, you're welcome to reject whatever you want.  IMHO replacing the
> XML file with a DB file is a worthy goal.  Having the data file remain
> a single file is also a worthy goal.  You may disagree with those
> goals, but then again you're not an implementor (anymore).
> 
> > I seriously doubt that any "embedded DBMS" would offer anything that
> > would _truly_ be smaller or simpler to work with.
> 
> Simpler from who's standpoint?  I'm looking at it from a user's
> standpoint.  You clearly are not (or you are grossly exagerating the
> abilities of the average user).

It is the _developer_ that will have to grapple with how to configure
access to wherever the data resides.  Which is _precisely_ the same
issue as determining what path to put in front of the initdb/pg_ctl
programs.

The more sets of libraries, the larger the number of DBMS choices, the
more complex will be the code, and the more likely that users will be
presented with a dialog reading:

 +----------------------------------------------+
 |   Unable to access Database At               |
 |   sqllite("/tmp/frobozz")                    |
 |  [ Abort ] [ OK ]                            |
 +----------------------------------------------+

(And what does [ OK ] mean?)

If the user is looking at _ALL_ of the components as being "magic,"
sqllite is no _less_ magic than PostgreSQL.
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/advocacy.html
"Much of this software was user-friendly, meaning that it was intended
for users who did not know anything about computers, and furthermore
had absolutely no intention whatsoever of learning."
-- A. S. Tanenbaum, "Modern Operating Systems, ch 1.2.4"