A ScalaQuery survey

[Stefan Zeiger]

Hi everyone,

We are currently in the planning stage for project Slick at Typesafe, the goal of which is to build the next-generation library for working with relational and non-relational databases. This is your opportunity to speak up! Are you using ScalaQuery (and are allowed to talk about it)? We'd like to hear about your use cases and your experience of using ScalaQuery for them. Are there any architectural changes you would like or are you happy with the current architecture? What were the main problems you encountered?

Or did you evaluate ScalaQuery but decided to use a different library in the end? Please let us know why ScalaQuery wasn't the right tool for you.

I'm looking forward to your replies, and please stay tuned for some exciting new database access features from Typesafe!

Best regards,
Stefan

--
Stefan Zeiger
Typesafe - Enterprise-Grade Scala from the Experts
Twitter: @StefanZeiger

[Alois Cochard]

I'm not using it yet, more on the NoSQL side of the force (used
Squeryl in past).

There is two thing I'm really looking forward:
- SIQ (like F# TypeProvider), mainly to use as [web] services client
- Abstraction layers to work with NoSQL datastore a la "spring-
data" (http://www.springsource.org/spring-data)

Graph DB / Document Store / Column Store

I want a framework that make me able to work on an abstract document/
graph/... store, making me able to switch implementation like I change
my panties.
So yeah, the big picture is the same as spring-data, but well.... FP
and Scala-friendly of course !

I just add that I want it to be less-intrusive possible (clear
separation with my model object).

Best regards,

Alois Cochard

> Typesafe <http://typesafe.com> - Enterprise-Grade Scala from the Experts
> Twitter: @StefanZeiger <http://twitter.com/#%21/StefanZeiger>

[ijuma]

Hi Stefan,

On Friday, 7 October 2011 09:27:05 UTC+1, Stefan Zeiger wrote:

Or did you evaluate ScalaQuery but decided to use a different library in the end? Please let us know why ScalaQuery wasn't the right tool for you.

We currently use Squeryl to access a legacy relational database. We had simple requirements and the fact that Squeryl allows tables to be defined by POSOs was the reason why we chose it over ScalaQuery for that project.

Best,

Ismael

[Jaime Jorge]

Hi Stefan.

I have been using scalaquery for almost an year now in my master
thesis and now in a software product.

First I would like to say that this is a great library, for which I
have found no bugs bothering me and it allows me to focus on my code
rather than on database storing stuff. Also, your feedback to question
here is quite hasteful.
For this I thank you and hope you keep this good work.

To a future version of this library (or in Slick for that matter), I
have a number of points I would like to discuss:

1) Database configuration/meta-information/automated management
One thing that highly annoys me is having to focus on whether a table
is created or not and only knowing this at runtime.
To the best of my knowledge scalaquery does not have information (or
meta information) of the database. Having a way to know whether a
given table is created or not (or more information like users,
privileges, table listing, etc) would be very good.
I understand that scalaquery is supposed to be database agnostic, i.e.
abstract over the concrete database implementation, which can make
this task harder since it ultimately depends on a specific DB.
However, I think we would greatly benefit from at least having meta
information from a set of DB vendors, even if for more unorthodox DBs
we had to implemented ourselves.
Now, ideally, what I really wish was not to have to think about this.
When I refer a table which was not created, the library could
automagically create it so I didn't have to do it myself. Automatic
management of the DB can be quite hard but is already done in some
places (MVC3 of ASP .Net fame) and I am quite envious of them.
If this cannot be done, at least provide the meta information so we
could do it ourselves.

2) Scala Integrated Query
I dont know if this is already planned in Slick, but SIQ posed
interesting question on avalanche querying.
Perhaps joined efforts? I'm stating this not knowing if you are
already working together.
Ideally, scalaquery (or Slick) could be to DB interface as ScalaCL
(http://code.google.com/p/scalacl/) is to scala loops.

3) Learn from LINQ and Rails
We are already in our niche since our queries rely on scala constructs
(fors) instead of having to learn a querying language, like LINQ.
However, they have great ideas and we should learn from them.
The ones I can think of right now (related to LINQ) are Deferred
Execution, Continuous LINQ and the Entity Framework (very very cool),
etc. But there are perhaps more interesting projects that I dont know
about.
I'm not saying we should implement them all, but they pose
improvements and I think we should be on the bleeding edge with them.
Also, Migrations from Rails (http://guides.rubyonrails.org/
migrations.html) looks like a very cool way of dealing with table and
schema changes.


This was not supposed to be a rant but more of a brainstorm of
possible ideas for the future Slick.
I will continue to use scalaquery since I think this is the way to go
for DB access in Scala.

Thanks

> Typesafe <http://typesafe.com> - Enterprise-Grade Scala from the Experts
> Twitter: @StefanZeiger <http://twitter.com/#%21/StefanZeiger>