On Thu, Jun 08, 2006 at 09:47:36AM -0700, Ben Pfaff wrote:
John Darrington <[EMAIL PROTECTED]> 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
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
