* CLSQL was not built for a web environment (A man can dream) and is not thread-safe. The clsql-helper[0] project was created to address this, among other things.
* CLSQL supports more databases. While CLSQL has its own bindings for every database (Like SQLAlchemy does, I think), Crane uses cl-dbi[1], which right now only supports the big three (Postgres, MySQL, SQLite3).
* Crane was originally conceived as a set of macros to reduce the verbosity of SQL, but I later decided it would be wiser to make it stand on its own.
* CLSQL's manual is what Crane's manual aspires to be. It's probably the most well-documented Common Lisp project.
* CLSQL only escapes strings, it doesn't do prepared statements, which is a huge security flaw.
CLSQL-Fluid [0][1] makes CLSQL thread-safe. (It also makes interesting reading as a clever use of CLOS.)
How is string escaping a huge security flaw? Certainly, you rely on the escaping being done correctly, which may be harder to get right than prepared statements, but assuming it's correct, it's just as secure, no?
I don't think most people have a solid sense of what is acceptable safety for dynamic SQL. The goal is to avoid injections, so you have to ensure that can't happen. If you have a reliable way to quote/escape literals (values and identifiers might have different syntax for this) you're good. It is risky, like all programming, to take matters into your own hands, but so is using a library you can't understand. Good luck.
CLSQL does the escaping itself. The question is whether a library that does prepared statements is reasonably expected to be safer than one that does escaping.
I haven't audited CLSQL's escaping myself, however. And I concede that using prepared statements takes one possible vulnerability off the table, which is nice. I was just wondering whether 'eudox had any specific reason to think that CLSQL's escaping was flawed.
Even assuming it's correct, I don't think that's a good enough guarantee. Prepared statements are as close as it gets to 'demonstrably correct', really smart escaping might be 'probably correct', but I will pick demonstrably over probably any day, especially in a web environment.
