Blobs is not a problem for 2⎕TF, since it will only ever output text,
correct? Then just using a plain text column will be good enough, and will
actually work right now.
As for blobs, I'm not sure we should care about that. After all, APL
doesn't support binary data anyway.
Regards,
Elias
On 13
Hi Blake,
we have 2⎕TF to convert APL functions and APL variables to text vectors
("bytes") and back.
So all that is needed for a native APL SQL database given a generic SQL
database is to declare
the objects properly (BLOB) and to call 2⎕TF before writing to, or after
reading from, the databa
Hi Elias,
not sure if I understood the problem correctly,
If the concern is that the first ravel element of the right arg is a
query string and the rest a some-how shaped
argument (and the total being ugly) then you could try the following
instead:
put the left arg (db) into the axis,
put th
Hi Elias,
Wow, looks cool!
/// Jürgen
On 04/11/2014 10:48 AM, Elias Mårtenson wrote:
I've been working on an SQL interface, and right now I'm at the point
where basic SQLite support works. Here's an example:
⍝ Load the native library
*'/home/emartenson/prog/apl-sqlite/lib_sqlite.so' ⎕
I think native SQL support is a really great thing. I prefer PostgreSQL,
so I might jump in in that area.
I feel strongly, though, that a keyed file system that works more native to
APL would be an important thing. Perhaps it can be built on top of what
you are doing - perhaps along the lines of
I'm following up to myself here.
I would like to have some advice from you guys about the design of the API.
Currently, the API for select and update is the following:
*database_id* FN '*statement*' [*argument* ...]
In other words, the first element of the ravel of the right-hand argument
is t
I've been working on an SQL interface, and right now I'm at the point where
basic SQLite support works. Here's an example:
⍝ Load the native library
* '/home/emartenson/prog/apl-sqlite/lib_sqlite.so' ⎕FX 'SQL'*
SQL
⍝ Open the SQLite database in the file /tmp/foo
*db ← SQL[1
