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 <dlamk...@gmail.com> 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. > >
