On 19/09/2019 15:20, Lassi Kortela wrote:
>> Oh yes. I've had maintain an SQL parser. :-|
>
> Wow. That kind of experience can change one's perspective on a lot of
> (hopefully just programming-related) things.

The SQL part if it wasn't traumatic at all - compared to the fact that
the original developer had, for mysterious reasons, decided to implement
their own version control system. We were forbidden to actually edit the
grammar file that drove the parser generator - instead, every change to
it after the initial version was encoded in a "sed" command in a shell
script that we could only append new things to the end of. I guess that
kind of numbed us all, and made everything else we did seem like
sweetness and light. But I digress...

>>
>> (sql-execute '("INSERT INTO foo VALUES(" myval1 ", " myval2 ")")
>>               '((:myval1 . 1) (:myval2 . 2)))
>
> This may actually be my favorite suggestion so far. The high-level DSL would hide all this stuff anyway for most code, so I don't think breaking the SQL string into parts like that is too ugly.

It looks ugly to the human eye, *but* it avoids having to parse strings...

>> But I always prefer the SSQL approach to this of just shoving scheme
>> values in using quasiquoting:
>>
>> (sql-execute `(insert (into foo)
>>                        (values #(,myval1 ,myval2)))
>
> This is definitely the way to go for most code, but I think we are in
> agreement that it belongs in a high-level DSL, and we need to figure out
> some arrangement for how to pass parameters to the DB driver at the low
> level.

Yeah!

--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/