Re: [Bug-apl] A really simple component-file implementation

[Elias Mårtenson]

Unfortunately, the only standard way to do it in a non-database-specific way is to use a separate table like you do.

I suppose that my SQL library could provide some kind of generalised API to it, but the problem is that different databases handle this in such a wildly different manner that it'd be hard to make it useful. Not even full-featured generic API's such as JDBC does this.

I'd suggest you stick with the separate table for now.

Oh, and I'll be committing a fix within the next half hour that actually implements transaction support for SQLite. Please use these commands instead of directly calling begin/commit as SQL calls, since the library will keep track of active transactions so that they can be rolled back on error.

Regards,

Elias

On 20 April 2014 13:51, David B. Lamkins <address@hidden> wrote:

Here's what I have so far (see attached). The tarball contains an APL
dump file and a test-case file.

I've stumbled upon a couple of GNU APL bugs; these have already been
reported to bug-apl and are documented in the test-case file.

I haven't yet done any performance testing. I'm intentionally leaning
toward readability rather than performance at this early stage.

There's certainly enough in this version to serve as a proof-of-concept.
It'd be worth exploring the merits of various alternatives, such as
using something besides 2⎕tf and ⍎ for encoding and decoding.

I didn't spend much time digging into SQLite's semantics; there's gotta
be a better way to get monotonically-increasing oids than by
manipulating a separate table.

One feature about which I feel strongly is the versioning of individual
components. This has no use at present, but will be important to
preserve the viability of component files when some aspect of the
implementation needs to change.