This seems to be a very promising and well designed project. However, there one part that puzzles me. On the one hand,<p><i>> SQL's declarativeness is preserved, not encapsulated in a lower level API that requires imperative and procedural code to get things done.</i><p>but on the other hand<p><i>> A significant part of optimizing a database abstraction layer is to choose for every situation the right balance between fine and large grained retrieval, and the optimal mix of laziness and eagerness.</i><p>Why is that even relevant? If the possibilities of SQL are preserved, why can't you simply let the database aggregate your data and make it return exactly what you need? ... which will be what you'll send to the user, after some formatting/templating, so the really wanted result can't be too big.<p>In other words, the difference between fine and coarse grained retrieval only matters if you have a big intermediate result that you have to process aside from the database because your ORM doesn't allow you to do that within the database. Since Squeryl claims to be different in that regard, why does the retrieval strategy even matter?
Squeryl is really awesome as far as scala-orms go.
I've used it in a couple of hobby projects and currently am using it in a bigger, and hopefully revenue bringing, project (a mix consisting of scala, wicket, squeryl and mysql. So far so good!)<p>Maxime, the guy behind squeryl is also very very helpful.
I've posted a few questions on squeryl's group and have never waited more than a day for a reply.<p>Perhaps it's because squeryl still is relatively unknown, but still, this goes to show that this project at least has a Human Interface which is always nice.<p>Lastly, hopefully squeryl will get some more attention now that Lift has given it some official attention.<p>Anyways, yeah. Squeryl. Cheers.