5 ms·

Quill – Compile-Time Language Integrated Query for Scala

51 points by fwbrasil 11y ago

Ciantic 11y ago
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.
- deleted 11y ago
  [deleted]
jaytaylor 11y ago
How is this significantly different or better than other longstanding Scala ORMs (e.g. Squeryl et. al.)?
- rusbus 11y ago
  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 11y ago
    Doobie is worth a look. I found slick a bit too magical...
- speedkills 11y ago
  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.
shubhamjain 11y ago
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 11y ago
  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 11y ago
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
- lmm 11y ago
  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)
- virtualwhys 11y ago
  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 11y ago
    > 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.
  - lmm 11y ago
    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.
emergentcypher 11y ago
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 11y ago
  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
  - emergentcypher 11y ago
    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?
    - fwbrasil 11y ago
      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 http://activate-framework.org.
  - fwbrasil 11y ago
    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.

51 points by fwbrasil 11y ago

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.

deleted 11y ago
[deleted]

jaytaylor 11y ago

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

rusbus 11y ago
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 11y ago
  Doobie is worth a look. I found slick a bit too magical...
speedkills 11y ago
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.

shubhamjain 11y ago

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 11y ago
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 11y ago

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

lmm 11y ago
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)
virtualwhys 11y ago
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 11y ago
  > 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.
- lmm 11y ago
  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.

emergentcypher 11y ago

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 11y ago
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
- emergentcypher 11y ago
  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?
  - fwbrasil 11y ago
    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 http://activate-framework.org.
- fwbrasil 11y ago
  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.