6 ms·

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 f

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.
    - eudox 12y ago
      This is something I've also noticed, and ironically it took writing an ORM to get it. I still think however that using Crane is worthwhile, even if I only use the migrations and connection management and write all my SQL by hand.
      - spacemanmatt 12y ago
        I recommend to anyone who thinks they want to use an ORM to start out by writing one, so they'll understand the product space and use cases better. It's my own little subversion of a crappy paradigm.
  - mercurial 12y ago
    > 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). I won't claim anything about people who write ORMs, but wanting to avoid a mess of concatenated strings in your code, which will blow up unexpectedly because your forgot a ',' in an if somewhere is a sane attitude to have. SQL strings are unsafe and compose very badly. As for claiming that "all code is string anyway", this is a strawman. Sure, "all code is string", except it can be statically checked for basic syntax errors.
deleted 12y ago
[deleted]
wes-exp 12y ago
The project page makes claims that it doesn't fall into common ORM traps such as recreating SQL syntax I don't see anywhere on the page where it is critical of recreating SQL syntax. I think the trap the SQL stuff is trying to avoid is doing everything through OOP method calls — something like Django's filter method, which the page explicitly calls out. Even if it was critical of recreating SQL, the point of an s-expression syntax is that it is still SQL, rather than a naïve reinvention that ends up missing important features.

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.
  - eudox 12y ago
    This is something I've also noticed, and ironically it took writing an ORM to get it. I still think however that using Crane is worthwhile, even if I only use the migrations and connection management and write all my SQL by hand.
    - spacemanmatt 12y ago
      I recommend to anyone who thinks they want to use an ORM to start out by writing one, so they'll understand the product space and use cases better. It's my own little subversion of a crappy paradigm.
- mercurial 12y ago
  > 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). I won't claim anything about people who write ORMs, but wanting to avoid a mess of concatenated strings in your code, which will blow up unexpectedly because your forgot a ',' in an if somewhere is a sane attitude to have. SQL strings are unsafe and compose very badly. As for claiming that "all code is string anyway", this is a strawman. Sure, "all code is string", except it can be statically checked for basic syntax errors.

deleted 12y ago

[deleted]

wes-exp 12y ago

The project page makes claims that it doesn't fall into common ORM traps such as recreating SQL syntax I don't see anywhere on the page where it is critical of recreating SQL syntax. I think the trap the SQL stuff is trying to avoid is doing everything through OOP method calls — something like Django's filter method, which the page explicitly calls out. Even if it was critical of recreating SQL, the point of an s-expression syntax is that it is still SQL, rather than a naïve reinvention that ends up missing important features.