bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] ISO Component File API preview


From: Blake McBride
Subject: Re: [Bug-apl] ISO Component File API preview
Date: Thu, 10 Jul 2014 17:48:56 -0500

The SQL layer is independent of APL or what you are storing on it.  All SQL sees is a bunch of strings.  The interpretation of those strings is GNU APL specific - just like STSC's.  No vendor's low level ISAM or VSAM file can communicate with any other vendor's APL ISAM or VSAM files without the specific APL that created it.

--blake


On Thu, Jul 10, 2014 at 5:42 PM, Peter Teeson <address@hidden> wrote:
The IPSA/STSC file system, also know as BSS (Backing Store (sub)System) ran as an independent process.
It so happened that it was only used via the APL interpreter. 
But were it available to the world at large other programs could have utilized it given the API and the code to access it.
IFRC it was layered on top of ISAM or maybe VSAM (I don't exactly remember)

Without having examined your keyed file system, and on no way making a value judgement, 
I infer from your comments in reply to my previous post that it is dependant on APL.

Am I correct?

Peter

On 2014-07-10, at 6:07 PM, Blake McBride <address@hidden> wrote:

On Thu, Jul 10, 2014 at 4:49 PM, Peter Teeson <address@hidden> wrote:

On 2014-07-10, at 5:22 PM, Blake McBride <address@hidden> wrote:
What I've been trying to convey (and clearly have failed on every attempt so far) is that an APL component file system must be file-centric. Every APL component file system that I've worked with or have read about has created a file to contain its APL data components.

Conceptually, yes.  Actually, what goes on under the hood is implementation specific.  In our present case, each component file would equate to an SQL table - not an SQL database.  This is very important.  So, if your applications uses 15 component files, that would be represented as 15 SQL tables in one SQL database.
In my experience with the IPSA/STSC file system a component file could store different data types in each component.
In my experience with various SQLs an SQL table only stores records whose fields are consistent for each record.
Therefore I do not agree that component file maps to an SQL table.

Peter


The way I implemented the keyed file system, which supports arbitrary nested arrays of varying size and types in each record, is as follows:

Each table is defined to have two columns (for data - not including the key).  One is a varchar, the other is a text.  I use GNU APL's 14 ⎕CR and ¯14 ⎕CR to convert between arbitrary nested APL arrays and string vectors.  If the string vector is short I use the varchar field.  If it is long, I use the text field.

So, SQL only sees varying length strings.  APL sees arbitrary APL nested (or not nested) arrays.

--blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]