Re: casefile random access

[John Darrington]

On Thu, Jun 08, 2006 at 09:47:36AM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     
     > Another problem I've encountered:  I'm getting this assertion in
     > casefile_append : 
     >
     >  assert (cf->mode == WRITE);
     >
     > Would it not be appropriate to allow write-after-read for random
     > casereaders ?
     
     It should be possible, although I'll note that writing is not
     associated with a casereader.

I mean't that would it be acceptable if casefile_get_random_reader
didn't put the casefile into READ mode ?
     
     I'm beginning to believe that casefiles should not be used for
     GUI access.  Instead, we should create a new, more dynamic
     structure for GUI access, one that supports the casefile
     operations.  For convenience, I'll call it a "flexfile", because
     it's flexible.  The GUI would use flexfiles where the TUI uses
     casefiles.  I'd write a wrapper that allowed them to be used
     interchangeably.

Rather than a wrapper, how about an inheritance mechanism?  So that a
flexifile inherits from a casefile, and can do everything a casefile
can and more. Or perhaps have them both implementing a common abstract
data type.  It might be easier to use that way.

But so long as a flexifile can participate in procedures and be
streamed into a casefile and vici-versa, then it should serve the purpose.
     
     I've been thinking about how to implement such a data structure.
     I think what would be wanted is a B-tree (as I think you
     mentioned), where each item in the tree is a group of columns.
     Inserting or deleting cases inserts or deletes items in the
     B-tree.
     
     Initially there would only be a single B-tree.  Inserting columns
     would create additional B-trees parallel to the initial one.
     Because each B-tree would have the same structure, only a single
     index would be necessary.
     
     This could be easily prototyped with Berkeley DB.  It sounds like
     you don't know about Berkeley DB, but it's enormously useful, so
     I'd recommend looking it up: http://dev.sleepycat.com/index.html


I'll have a look at that.

In the mean time, I've just commented out that assertion in
casefile_append, and so far, haven't noticed any untoward consequences.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature