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 <peter.tee...@icloud.com> 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 <blake1...@gmail.com> wrote: > > On Thu, Jul 10, 2014 at 4:49 PM, Peter Teeson <peter.tee...@icloud.com> > wrote: > >> >> On 2014-07-10, at 5:22 PM, Blake McBride <blake1...@gmail.com> 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 > > > > >
