in reply to Database Synchronization

Don't bother with "flat-file databases", just use BerkeleyDB. It supports (i think) everything you need.

Start with the Berkeley DB Tutorial and Reference Guide, especially with What is Berkeley DB? and What Berkeley DB is not, and convince yourself it's what you need, then get it ;)

update: A always, BerkleyDB's simpler cousin DB_File is also available ;)(and this might be interesting as well)

MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Database Synchronization
by Dr. Mu (Hermit) on Dec 03, 2002 at 18:28 UTC
    Thank you for the pointer to Berkeley DB. Having read portions of the tutorial, I can assure you that knowing about this when I began the project would've saved me hours of coding! And yet this one quote from that tutorial gives me pause:
    Berkeley DB replication groups consist of some number of independently configured database environments. There is a single master database environment and one or more client database environments. Master environments support both database reads and writes; client environments support only database reads.
    This speaks directly to my synchronization issue, as it will be necessary to modify a client (clone) database offline for later synchronization to the master. This is necessary during data entry, for example, since our data entry person is a volunteer working at home with a dial-up internet connection. For her to do her work while maintaining the persistent connection required by a purely transactional system is expecting too much. Better, would be for her to have a clone of the master database which gets modified. When she connects to the server, those modifications would get uploaded and any changes made in the interim to the master database would get downloaded. Synchronization conflicts occur when the same record (or field) gets changed in two different copies of the database. They can either be logged for later human intervention or dealt with algorithmically.

    What I was hoping for was a module which automated the synchronization bookkeeping with hooks to the main program for dealing with conflicts. One that also includes journaling for reversing changes would be a plus.

[reply]
      I've not seen anything dealing with that issue (and I like to keep things as simple as possible).

      Here's what I see happening. Your data entry person has a read-only copy of the database, and any changes she makes do not get recorded in the database, but a file which she then uploads to your server, and which then hopefully gets incorporated into the master database.

      You can have a special program on the server to control this, where the data-entry person can chose to which of the pending updates get entered into the master.

      You can build your own journaling system around that, or you can build one from the logs.

      I'd like to see what you come up with ;)

      MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
      ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]

In Section Seekers of Perl Wisdom