
Quill – Compile-Time Language Integrated Query for Scala - fwbrasil
http://getquill.io
======
shubhamjain
Sigh! Shouldn't people do a bit of googling before naming their project /
business? This is third project with the same name. We have QuillJs[1], a rich
text editor and Quill[2], an interactive grammar tool.

[1]: [https://github.com/quilljs/quill](https://github.com/quilljs/quill)

[2]: [https://www.quill.org/](https://www.quill.org/)

~~~
emidln
There's a clojure/clojurescript library for interactive drawing (layered over
Processing and ProcessingJS)[1] and at least one commercial product[2] that
I'm aware of. Picking unique names across languages/platforms/sectors is hard
and likely unreasonable.

[1] - [https://github.com/quil/quil](https://github.com/quil/quil)

[2] -
[https://www.narrativescience.com/quill](https://www.narrativescience.com/quill)

------
oever
Is there a library for Scala that is as powerful as Persistent with Esqueleto
in Haskell? Persistent is a DSL for the database model and Esqueleto is a
library for writing SQL that is validated against the database model at
compile time.

[http://www.yesodweb.com/book/sql-joins](http://www.yesodweb.com/book/sql-
joins)

~~~
virtualwhys
As powerful as Persistent with Esqueleto? Slick, Squeryl, Quill, sqlTyped,
probably others. Scala's type safe query dsl story is exceptionally good (I'd
go so far as to say unrivaled, but working in Scala I'm biased).

Don't forget JDBC, Haskell is in the stone ages on this front. Like the JVM so
much engineering has gone into JDBC, and all major database vendors have
drivers for it. Not the case for Haskell, and even if it were, Esqueleto
offically supports a single database, Postgres.

Haskellers in the know are well aware of deficiencies in this area[1]. Perhaps
down the road things will change, but for now I couldn't help but rofl at the
question ;-)

[1] [http://www.haskellforall.com/#databases-and-data-
stores](http://www.haskellforall.com/#databases-and-data-stores)

~~~
tome
> Esqueleto offically supports a single database, Postgres.

This is not so. It supports at least persistent-mysql, persistent-postgresql,
persistent-sqlite, according to
[https://github.com/prowdsponsor/esqueleto/](https://github.com/prowdsponsor/esqueleto/)

Perhaps you are thinking of Opaleye, which does only support Postgres.

------
jaytaylor
How is this significantly different or better than other longstanding Scala
ORMs (e.g. Squeryl et. al.)?

~~~
rusbus
The general theme of this seems to be: Reduce boilerplate with compiler
macros.

This is pretty similar in functionality to Slick. From reading the docs, it
seems like it reduces some of the boilerplate (eg. in Slick you need to define
both case classes and tables) but at the cost of potentially less
customization.

Additionally, while Slick has a layer that you can use to actually create your
database tables, this appears to be query layer only. That isn't a problem, I
think. I found Slicks ddl stuff was mostly an antipattern in production (you
should use an actual migration framework).

Another big advantage Quill has over slick is how easy it is to see the
resulting query.

~~~
estefan
Doobie is worth a look. I found slick a bit too magical...

------
Ciantic
Structural typing is more natural with SQL. Because of this I wish this worked
with anonymous records instead of case classes. You rarely need all fields
returned by query when filling UI.

------
emergentcypher
Does it require every field of the case class to be present in the result set?
Can it handle missing columns or fields with default values?

~~~
Ciantic
I'd argue if you return case class with only some fields, your typing is
broken. It should return a record when you are trying to get only some of the
columns, but I don't find an example of that.

Partly the problem is there is no good defacto Record implementation in Scala
so the library makers are not yet taking this seriously. There are few
competing (?) that I've been looking at, one by cvogt here:
[https://github.com/cvogt/compossible](https://github.com/cvogt/compossible)
and one called Scala records here: [https://github.com/scala-records/scala-
records](https://github.com/scala-records/scala-records)

~~~
fwbrasil
Interesting! I was actually considering implementing a record system when
designing quill, but wasn't sure if it'd be convenient to the users since it
requires learning one more DSL.

Currently, quill provides two alternatives:

1\. Select tuples instead of case classes

2\. As the mapping case classes are simple to create, it's possible to define
an additional one only with the fields the user wants to select in the query.

This means that's possible select any subset of the database structure. I
still wonder if records would be a better solution though.

~~~
Ciantic
I think records are better solution than tuples in most cases, they provide
type safety, contain the field names and auto-completion for fields. Scala-
records makes casting records back to case classes easy.

Defining tables as case classes is pretty neat, but option to get Records out
of queries would be preferred.

Though I can't figure out which Scala record implementation is going to
prevail, making the choice hard, but creating own record type is probably not
the way.

