4 ms·

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

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