Comments on: A Type-Safe Database Query DSL for Scala

By: Groovy创始人：Java面临终结 Scala将取而代之 | NeXT

Groovy创始人：Java面临终结 Scala将取而代之 | NeXT — Mon, 14 Mar 2011 13:51:04 +0000

[...] > 用于JDBC类型安全查询的一个Scala版LINQ，顺便再了解下DBC。 [...]

By: Groovy创始人：Java面临终结 Scala将取而代之 | Opeweblabs

Groovy创始人：Java面临终结 Scala将取而代之 | Opeweblabs — Fri, 20 Aug 2010 06:16:26 +0000

[...] 用于JDBC 类型安全查询的一个Scala版LINQ，顺便再了解下DBC。 [...]

By: Stefan Zeiger

Stefan Zeiger — Tue, 10 Nov 2009 20:57:42 +0000

@ctran: Scala 2.8 is missing. ScalaQuery has matured enough to for an official 1.0 release. I’m just waiting for Scala 2.8.0.

By: ctran

ctran — Tue, 10 Nov 2009 19:37:01 +0000

This is pretty cool. I’m surprised this didn’t get more attention/momentum into a complete solution. What’s missing?

By: Интересные ссылки №194 - rssh - блог разработчиков

Интересные ссылки №194 - rssh - блог разработчиков — Fri, 30 Oct 2009 07:43:42 +0000

[...] В Scala LINQ может быть сделано на основе плагина компилятора: http://www.sts.tu-harburg.de/people/mi.garcia/ScalaQL/ Подобный подход применим и к JPA. http://szeiger.de/blog/2008/12/21/a-type-safe-database-query-dsl-for-scala/#more-24 [...]

By: Colin Howe

Colin Howe — Mon, 14 Sep 2009 13:03:29 +0000

@Daniel @Stefan Just came across this. I think using where is clearer than if – it implies that it will be part of the query and not a condition that is applied afterwards. It also leaves open the possibility of using if instead of where when you know that the you want to do the filtering client-side instead of server-side. Just my 2p worth

@Daniel This is awesome I’ve been thinking that Scala must have some potential for doing really neat things to tidy up database access in a nicer way than Hibernate does

By: Stefan Zeiger

Stefan Zeiger — Mon, 15 Jun 2009 19:00:06 +0000

@Daniel: Initially I wanted to use filter() for conditions but I changed it to a separate where() method shortly before I posted this article. The filter(… => Boolean) method is needed if you want to write “Join(u,o) < - Users join Orders" instead of "uo <- Users join Orders; val Join(u,o) = uo" because the compiler creates a filter() call for such a pattern. If I added a filter(... => Column[Boolean]) method for conditions, an error like if(u.id != 42) instead of if(u.id isNot 42) would go unnoticed. Of course, currently I have neither of those methods. I’ll have to see which one to add back when unions and more useful joins are implemented.

And yes, generating the table classes from a DB schema would certainly be nice to have but it’s not one of my top priorities at the moment. Patches are welcome, if someone else wants to have a crack at it

By: Daniel Sobral

Daniel Sobral — Tue, 09 Jun 2009 22:15:04 +0000

Another idea… if you could make a Scala code generator from DB schema, for the table objects, it would be pretty cool. One could get an existing database (or one generated by other tools) up and running that much quicker.

I imagine an interpreter session, where I have an sf session and just do:

sf withSession { generateScaffold (List(”Users”, “Orders”), “myTables.scala”) }
:load myTables.scala
sf withSession { … }

BTW, I forgot to remark on it, but I loved the idea of a type-safe database framework.

By: Daniel Sobral

Daniel Sobral — Tue, 09 Jun 2009 22:01:49 +0000

Why did you opt for a “where” method, instead of taking advantage of “if” though a filter method on query? If you overloaded filter to receive either a function into Boolean or a function into Column[Boolean] (if I understand how “where” works), then it could be used to work either as a filter over an iterator, or a query modifier.

By: Stefan Zeiger

Stefan Zeiger — Sat, 21 Feb 2009 13:32:04 +0000

Public repo now available. See next post for details.