Comments for szeiger.de

Comment on Efficient Parameterized Queries in ScalaQuery by Stefan Zeiger

Stefan Zeiger — Fri, 16 Dec 2011 10:09:44 +0000

You can use an existing solution like Spring JdbcTemplate or Java EE for declarative transactions. You long as you can get an (injected) java.sql.Connection which has been configured for the transaction by the container, you can wrap it in an org.scalaquery.Session and use this container-managed session instead of ScalaQuery’s own session management.

Comment on Efficient Parameterized Queries in ScalaQuery by trucmuche

trucmuche — Wed, 14 Dec 2011 23:33:25 +0000

What about transactions in app or business layer ??

How can i start a transaction in my app/business layer, in a declarative way or another not intrusive way ??

Thank’s for reply.

Comment on Type-Level Computations with Functional Dependencies by Stefan Zeiger

Stefan Zeiger — Tue, 20 Sep 2011 09:26:56 +0000

Yes, this will do away with the Tuple22 limit. Typed queries wouldn’t work with Seqs or Maps. The only real alternative to Tuples are HLists (or HArrays). There is no production-ready HList implementation for Scala that I am aware of but new system is extensible and if you have an HList, it should be possible to make ScalaQuery use it with only a few lines of code.

Comment on Type-Level Computations with Functional Dependencies by Hugh

Hugh — Mon, 19 Sep 2011 16:46:47 +0000

Will nested tuples overcome the limit of 22 imposed by the current implementation? I’m assuming it will, which begs the question:why did you choose a Tuple implementation, which has a hard upper limit, over a Seq or Map implementation, which has no upper limit?

The upper limit of 22 is way too restrictive for real-world scenarios. I just downloaded your code for nested-tuples and I’m going to give it a whirl. We really like your approach in general, but the hard upper limit gives us pause

Comment on Removing Libraries and HomeGroup icons from the Windows 7 desktop by James Y.

James Y. — Sat, 04 Jun 2011 19:10:52 +0000

Yes, Kelvin’s method worked great, now if only someone could show a method like that for the God Forsaken Libraries folder to be removed I’d be very thankful! ;D

Comment on A Zipper for scala.xml by Tony

Tony — Mon, 16 May 2011 20:32:18 +0000

This has been a life saver for me. It’s really unfortunate that scala neither includes xpath axes functionality, nor xpath functionality generally. It would be nice to take these ideas and get someone like Michael Kay (of Saxonica) involved – he is a key driver of the Xpath / XQuery / XSLT standards and wrote the awesome Saxon libraries.

Comment 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。 [...]

Comment on New ScalaQuery Features by Stefan Zeiger

Stefan Zeiger — Tue, 21 Dec 2010 00:12:22 +0000

An inner join is best written with the implicit syntax where you can use as many tables as you need, e.g. “for(t1 < - Table1; t2 <- Table2 if t1.id === t2.id; t3 <- Table3 if t1.id === t3.id) yield t1.a ~ t2.b ~ t3.c". Explicit joins over more than two tables have an awkward syntax and they still suffer from a code generation bug at the moment. See https://github.com/szeiger/scala-query/issues#issue/4 for details.

Comment on New ScalaQuery Features by Martin

Martin — Sat, 18 Dec 2010 00:02:52 +0000

Stefan, what would be your recommendation for an inner join of three or more
tables. Is it possible to post an example

Comment on Formal Language Processing in Scala, Part 1 by MIlos

MIlos — Sun, 12 Dec 2010 14:02:52 +0000

Thanks for these articles, I’ve been looking for something like this for quite some time now.
You cover two topics that i am very interested in: scala, parsing.
I used to have to read big ugly books about compilers but your examples make things easy
Keep up the good work.