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

[Elias Mårtenson]

Yes, that's how I work too. My home server contains a Postgres instance that I use for pretty much everything. It's quite convenient.

Regards,

Elias

On 10 July 2014 12:53, Blake McBride <address@hidden> wrote:

Greetings,

PostgreSQL is very important to, at least, me.  I do a lot of production work in PostgreSQL.  I like SQLite too, but I would only use it when the data didn't relate to anything but APL.  Here is what I propose.  Since your component file system rides on top of SQL, and the standard doesn't know or care about anything below the APL level, we should add a function that allows the user to specify the database information (dbname, user, password, etc.).  That call would be made as sort of a setup step.  Once that setup step is specified, all of the standard API should work as described.

This will give us a totally standard API.  If someone wants to switch to GNU APL, all they have to do is add one function to specify the database.  Not too much to ask.

We kind of have to do this.  Even with SQLite, you still have to specify the database name (I presume one database contains many component files).

Thanks.

Blake

On Wed, Jul 9, 2014 at 9:44 PM, David B. Lamkins <address@hidden> wrote:

I'm certainly willing to consider alternatives. IIUC, lib_sql also
supports PostgreSQL. Anything else?

How do I tell lib_sql to use a PostgreSQL server?

The argument in favor of SQLite, of course, is that it's serverless. No
additional setup (beyond the installation of the library) required.

Would there be any additional benefits or concerns when connecting to a
PostgreSQL server?

As you've no doubt noticed, there's nothing in the code (or in the
standard API) to acknowledge or support the notion of multiple users.
Again: point in favor of SQLite...

On Thu, 2014-07-10 at 10:25 +0800, Elias Mårtenson wrote:
> I was looking at your code, and I noticed that it's SQLite-specific.
> WOuldn't it make sense to make it SQL-implementation-agnostic?
>
>
> Based on what I can see, the only SQLite-specific SQL you have in
> there is "replace into" which I had never heard about before.
>
>
> Regards,
> Elias
>
>
> On 9 July 2014 01:22, David Lamkins <address@hidden> wrote:
>         I haven't yet written test scripts, but I've informally tested
>         all of the functions and am reasonably confident that the
>         component file API is complete and correct.
>
>
>         If you'd like to try out the API while I'm working on scripted
>         test cases, the repo is:
>
>         https://github.com/TieDyedDevil/iso-apl-cf
>
>
>         You'll find documentation is in the comments and in Annex A of
>         the ISO 13751 standard.
>
>
>         The standard "specifies a minimal set of functions which a
>         conforming implementation must provide"; I've implemented all
>         of these. I've also added several useful functions not
>         mentioned in the standard, including component inquiry,
>         component drop, and transaction support.
>
>
>
>         Note that the code is not packaged for my package manager; I
>         assume that the component file implementation would become an
>         L3 library in the event it's adopted for inclusion in GNU APL.
>
>
>         Júergen, I've specified the GPLv3 license since that's what
>         GNU APL uses. If there's a more appropriate choice of license
>         for this library, please let me know.
>
>         --
>         "The secret to creativity is knowing how to hide your
>         sources."
>            Albert Einstein
>
>
>         http://soundcloud.com/davidlamkins
>         http://reverbnation.com/lamkins
>         http://reverbnation.com/lcw
>         http://lamkins-guitar.com/
>         http://lamkins.net/
>         http://successful-lisp.com/
>
>