

Squeryl: A concise, type-safe Scala ORM and DSL - stephenjudkins
http://squeryl.org/

======
vog
This seems to be a very promising and well designed project. However, there
one part that puzzles me. On the one hand,

 _> SQL's declarativeness is preserved, not encapsulated in a lower level API
that requires imperative and procedural code to get things done._

but on the other hand

 _> 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._

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.

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?

~~~
barrkel
I agree with you in the context of a single table. Introduce something a
little more complicated, such as master/detail relations, however, and things
aren't so straightforward. The mere fact of a foreign key in the child that
the ORM can pull out of DB metadata (or have manually described to it, etc.)
isn't enough to know if it's reasonable to be lazy or eager in retrieving
child rows when getting the parent.

~~~
vog
_> I agree with you in the context of a single table._

I actually had complex joins in mind.

A good ORM (in the sense that most ORMs _aren't_ good by this definition)
should retrieve the child rows if and only if they are required for the final
result. And it should request exactly the columns that are needed by the
result. And, as already pointed out in my previous comment, it should hand
over the aggregating to the database - that's one of the main things databases
are good for.

~~~
ShabbyDoo
"And it should request exactly the columns that are needed by the result"

Gavin King (the Hibernate guy) argued that all columns should be fetched by
default because (A) the marginal cost of doing so is very low once the db has
taken the disk hit for any data in the row and (B) an in-memory object cache
is easy/efficient if entire objects (rows) are cached at once. I might be
paraphrasing a bit much.

One could argue that, when some databases can return a subset of column data
from indexes (vs eating the disk hit for the row data) that limiting the
columns fetched could be much more efficient.

There are probably very few areas of any app I've worked on where I would have
gotten significant performance gains by limiting results to a subset of
columns.

~~~
barrkel
It depends. If there are a lot of columns and you're only interested in a
handful, and there's an index that contains all those columns, it should be
much cheaper just to select the interesting columns, as all the data needed
can be retrieved from the index. Asymptotically, the size ratio between the
columns selected and the columns in the table gives the speedup.

------
jsean
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!)

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.

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.

Lastly, hopefully squeryl will get some more attention now that Lift has given
it some official attention.

Anyways, yeah. Squeryl. Cheers.

------
mhansen
Needs a code example on the front page.

~~~
pjscott
I was about to post the same thing. Code examples are the second thing I look
at when I see the web page for some new library or framework. The first thing
I look at is the one-sentence description right below the title, if any.

You may notice that this maps pretty well to how pages on Github are set up.
That's because Github has really nice design.

------
rue
Seems decent enough, I should reintroduce to Scala.

The website does not degrade well, though: no JS == no code listings.

~~~
vog
It also uses a strange apostrophe replacement in words like _won't_ and
_SQL's_. That is, it uses an accute accent over a space (’) instead of a
simple apostrophe (').

