5 ms·

Crane: An ORM for Common Lisp

99 points by eudox 12y ago

huehue 12y ago
The code is a joy to read. This is not how I remember CL.
- ska 12y ago
  Conversely, that is exactly how I remember CL. (e.g. http://weitz.de/ http://weitz.de/)
- PuercoPop 12y ago
  I uses the 'ArielNetwork/Fukamachi' style which has a lot of @ reader macros and recommends a one package per file. Although not on all files.
mantrax5 12y ago
The project page makes claims that it doesn't fall into common ORM traps such as recreating SQL syntax, locking you into a limited subset of it, yet... just a few sections below it shows exactly that. I'm sorry, but building SQL out of s-expressions doesn't count as "functional SQL". It's just crippled declarative normal SQL, made from s-expressions. There's also the usual for ORMs display of superficial understanding of transactions with a "with-transactions" global switch, as if transactions are something you can just sprinkle on top of your finished product like an exotic condiment, and get greater goodness. This is not how SQL works. Even the "fine-grained" transactions interface doesn't expose common-place and crucial features such as transaction isolation levels, store points, selecting for update and lock in share mode. If you're reading this and thinking "this guy's just listing arbitrary niche features no one uses", then you have no business using or, god forbid, writing ORMs, because the first time you get serious traffic hitting your database you'll end up with inconsistent data state, and have no clue how it happened (blame MySQL? Sure, blame MySQL). SQL ORMs feel oddly anachronistic in 2014. People have largely moved to persisting objects with databases built for persisting objects, leaving SQL databases to be used where they work best - for relational data queries, without quirky layers in between caller, query and results. Plus... and I realize maybe it's just my bias against ORMs, but "an ORM for Common Lisp" reads a bit like "we ported AIDS to heaven". Just because you could do it, didn't mean you should've.
- lucian1900 12y ago
  SQL libraries don't have to be ORMs or useless. SQLAlchemy has a core SQL layer that lets you compose SQL better than by bashing strings together and it handles the transaction lifecycle correctly for you through its unit of work pattern (the session). While all I know of Crane is this page, it would appear to follow the same design, there its "filter" shortcut is built on top of the lower layer, which is also available to use directly.
  - eudox 12y ago
    >While all I know of Crane is this page, it would appear to follow the same design, there its "filter" shortcut is built on top of the lower layer, which is also available to use directly. Essentially this. To be perfectly clear: Crane doesn't share SQLAlchemy's data mapper/unit of work pattern, it is much closer to regular active record. However, it still provides good flexibility by using SxQL and not pretending SQL doesn't exist.
  - mantrax5 12y ago
    > SQL libraries don't have to be ORMs or useless. It's true, they don't have to be useless. The problem is that people who end up writing most of those libs are: 1. People who have very superficial knowledge about range of features, semantics, and algorithms behind SQL. 2. People who are motivated by an irrational yucky feeling about code in strings (as if their Lisp/Python/Java/etc. source isn't just code in a string itself). 3. People who are typically very averse towards learning new technologies. They are blissfully unaware of all the ways they can persist their objects without "mapping" them. They know in depth and favor one application language, and they've stored data in SQL a few times, so let's do everything in SQL, because learning is hard, but writing abstractions is cool. It feels like an achievement.
    - spacemanmatt 12y ago
      I've noticed that as my SQL skills evolved, I became more and more repulsed by ORMs. Now when I write a schema, I design a remote facade and map that 1:1 to a service object in client code. It is the best way I have contrived in a commercial setting (e.g. constrained in every way) to get testing isolation between database and client code to be useful.
rgrau 12y ago
How does it compare to clos + elephant? I have just used it (elephant) for really simple things, but they seemed to work really well. Also with sql backends
- eudox 12y ago
  From what I've seen, Elephant gives you an interface to some persistent data structures then finds a way to back them with SQL or something else. This doesn't have that kind of backend hiding, it's meant to be tightly integrated with SQL.
patrickmay 12y ago
I'm currently using Postmodern (http://marijnhaverbeke.nl/postmodern/ http://marijnhaverbeke.nl/postmodern/). How does Crane compare?
- PuercoPop 12y ago
  Postmodern is built upon s-sql while Crane on sxql. Also Postmodern's DAO doesn't strive to be an ORM.
  - eudox 12y ago
    Specifically, S-SQL only escapes SQL and does parametric statements (Interpolation) only manually, while SxQL is safe by default: Every object in an SQL query is passed in an injection-safe way.
    - patrickmay 12y ago
      That's a good non-functional feature. Does Crane offer any functional capabilities over Postmodern?
ScottBurson 12y ago
How does it compare to CLSQL? Looks mostly pretty similar at first glance, though the automatic migrations look like a nice addition.
- eudox 12y ago
  Some differences and similarities: * 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. [0] https://github.com/AccelerationNet/clsql-helper https://github.com/AccelerationNet/clsql-helper [1] https://github.com/fukamachi/cl-dbi https://github.com/fukamachi/cl-dbi
  - ScottBurson 12y ago
    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? [0] http://common-lisp.net/project/clsql-fluid/ http://common-lisp.net/project/clsql-fluid/ [1] https://github.com/html/clsql-fluid https://github.com/html/clsql-fluid
    - eudox 12y ago
      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.

99 points by eudox 12y ago

huehue 12y ago

The code is a joy to read. This is not how I remember CL.

ska 12y ago
Conversely, that is exactly how I remember CL. (e.g. http://weitz.de/ http://weitz.de/)
PuercoPop 12y ago
I uses the 'ArielNetwork/Fukamachi' style which has a lot of @ reader macros and recommends a one package per file. Although not on all files.

mantrax5 12y ago

The project page makes claims that it doesn't fall into common ORM traps such as recreating SQL syntax, locking you into a limited subset of it, yet... just a few sections below it shows exactly that. I'm sorry, but building SQL out of s-expressions doesn't count as "functional SQL". It's just crippled declarative normal SQL, made from s-expressions. There's also the usual for ORMs display of superficial understanding of transactions with a "with-transactions" global switch, as if transactions are something you can just sprinkle on top of your finished product like an exotic condiment, and get greater goodness. This is not how SQL works. Even the "fine-grained" transactions interface doesn't expose common-place and crucial features such as transaction isolation levels, store points, selecting for update and lock in share mode. If you're reading this and thinking "this guy's just listing arbitrary niche features no one uses", then you have no business using or, god forbid, writing ORMs, because the first time you get serious traffic hitting your database you'll end up with inconsistent data state, and have no clue how it happened (blame MySQL? Sure, blame MySQL). SQL ORMs feel oddly anachronistic in 2014. People have largely moved to persisting objects with databases built for persisting objects, leaving SQL databases to be used where they work best - for relational data queries, without quirky layers in between caller, query and results. Plus... and I realize maybe it's just my bias against ORMs, but "an ORM for Common Lisp" reads a bit like "we ported AIDS to heaven". Just because you could do it, didn't mean you should've.

lucian1900 12y ago
SQL libraries don't have to be ORMs or useless. SQLAlchemy has a core SQL layer that lets you compose SQL better than by bashing strings together and it handles the transaction lifecycle correctly for you through its unit of work pattern (the session). While all I know of Crane is this page, it would appear to follow the same design, there its "filter" shortcut is built on top of the lower layer, which is also available to use directly.
- eudox 12y ago
  >While all I know of Crane is this page, it would appear to follow the same design, there its "filter" shortcut is built on top of the lower layer, which is also available to use directly. Essentially this. To be perfectly clear: Crane doesn't share SQLAlchemy's data mapper/unit of work pattern, it is much closer to regular active record. However, it still provides good flexibility by using SxQL and not pretending SQL doesn't exist.
- mantrax5 12y ago
  > SQL libraries don't have to be ORMs or useless. It's true, they don't have to be useless. The problem is that people who end up writing most of those libs are: 1. People who have very superficial knowledge about range of features, semantics, and algorithms behind SQL. 2. People who are motivated by an irrational yucky feeling about code in strings (as if their Lisp/Python/Java/etc. source isn't just code in a string itself). 3. People who are typically very averse towards learning new technologies. They are blissfully unaware of all the ways they can persist their objects without "mapping" them. They know in depth and favor one application language, and they've stored data in SQL a few times, so let's do everything in SQL, because learning is hard, but writing abstractions is cool. It feels like an achievement.
  - spacemanmatt 12y ago
    I've noticed that as my SQL skills evolved, I became more and more repulsed by ORMs. Now when I write a schema, I design a remote facade and map that 1:1 to a service object in client code. It is the best way I have contrived in a commercial setting (e.g. constrained in every way) to get testing isolation between database and client code to be useful.

rgrau 12y ago

How does it compare to clos + elephant? I have just used it (elephant) for really simple things, but they seemed to work really well. Also with sql backends

eudox 12y ago
From what I've seen, Elephant gives you an interface to some persistent data structures then finds a way to back them with SQL or something else. This doesn't have that kind of backend hiding, it's meant to be tightly integrated with SQL.

patrickmay 12y ago

I'm currently using Postmodern (http://marijnhaverbeke.nl/postmodern/ http://marijnhaverbeke.nl/postmodern/). How does Crane compare?

PuercoPop 12y ago
Postmodern is built upon s-sql while Crane on sxql. Also Postmodern's DAO doesn't strive to be an ORM.
- eudox 12y ago
  Specifically, S-SQL only escapes SQL and does parametric statements (Interpolation) only manually, while SxQL is safe by default: Every object in an SQL query is passed in an injection-safe way.
  - patrickmay 12y ago
    That's a good non-functional feature. Does Crane offer any functional capabilities over Postmodern?

ScottBurson 12y ago

How does it compare to CLSQL? Looks mostly pretty similar at first glance, though the automatic migrations look like a nice addition.

eudox 12y ago
Some differences and similarities: * 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. [0] https://github.com/AccelerationNet/clsql-helper https://github.com/AccelerationNet/clsql-helper [1] https://github.com/fukamachi/cl-dbi https://github.com/fukamachi/cl-dbi
- ScottBurson 12y ago
  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? [0] http://common-lisp.net/project/clsql-fluid/ http://common-lisp.net/project/clsql-fluid/ [1] https://github.com/html/clsql-fluid https://github.com/html/clsql-fluid
  - eudox 12y ago
    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.