Quill – Compile-Time Language Integrated Query for Scala | Hacker News Reader

Quill – Compile-Time Language Integrated Query for Scala

getquill.io

51 pointsfwbrasil18 comments

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

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

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

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

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

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

> 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/

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

I fear JDBC is actually holding Scala database access back. It's fundamentally blocking and just generally not a nice API, but because it's so established better alternatives can't gain any traction.

How is the article not exactly that? (The DSL for the model here is just Scala case class declarations, but they make a pretty good DSL for such things)

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

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.

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

Taking a quick look the examples are better out of the gate than slicks docs are after a couple of years. Great examples are worth a lot in my book.

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.

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?

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 and one called Scala records here: https://github.com/scala-records/scala-records

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.

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.

I'm thinking more the case where my case class has more fields than are in one database table. For example, what if the Person class has a List[Address] whose values are stored in another table? I guess you would suggest separating the address list from the Person model?

Yes, quill is not an ORM. The case classes need to be flat as the database rows are, so relationships need to be mapped using reference fields (ids) to other rows (case classes).

There's no "one size fits all". If quill's abstraction level is not enough for your domain, I suggest trying out http://activate-framework.org.

Reply on news.ycombinator.com