add support for auto encoding of wrapped types

[godenji]

This PR addresses ID handling issue

[fwbrasil]

Is filter comparing an Int (_.value) to a Wrapped instance?

[godenji]

it is, but should not, I'll update PR, all the queries should be against Entity with wrapped param as argument.

[gustavoamigo]

@godenji what problem does this PR solve?

[godenji]

@gustavoamigo automatic encoding of, for example, Id types (or any single value constructor that extends MappedValue). Basically eliminates the need to define implicit encoder/decoder boilerplate for every custom wrapped type.

Can also be used as basis for Id types like primary/foreign keys. Something like:

trait Id[T] extends Any with MappedValue[T] {
  def empty: Boolean = value == Id.zero
}
object Id{
  private val(intZero,doubleZero,longZero,stringZero,uuidZero) = (
    0, 0.0, 0L, "", new java.util.UUID(0L,0L)
  )
  /** default Id value's type */
  type Value = Int

  /** default Id */
  type Default = Id[Value]

  /** default zero value */
  val zero: Value = intZero
}

case class UserId(value: Id.Default) extends Id[Id.Default]
case class CompanyId(value: Id.Default) extends Id[Id.Default]
...

Although there's probably a better approach (i.e. not relying on static object).

[godenji]

@gustavoamigo @fwbrasil @jilen @lvicentesanchez can you guys take another look at this?

Maybe I didn't explain clearly enough: this PR gives us mapping of wrapped types for free

From the updated README section on encoding

import io.getquill.sources._

case class UserId(value: Int) extends AnyVal with WrappedValue[Int]
case class User(id: UserId, name: String)

val q = quote {
  (id: UserId) => for {
    u <- query[User] if u.id == id
  } yield u
}
db.run(q)(UserId(1))

// SELECT u.id, u.name FROM User u WHERE (u.id = 1)

Pretty simple implementation, just a couple of traits and an implicit conversion. Scala's a strongly typed language, let's use types to our advantage 😄

[lvicentesanchez]

I need to look at this more carefully but as I use value classes a lot not having to write wrappers would be great. I'm going to check out the PR tomorrow and use it on my pet project.

Sent from my iPad

On 25 Feb 2016, at 23:39, godenji notifications@github.com wrote:

@gustavoamigo @fwbrasil @jilen @lvicentesanchez can you guys take another look at this?

Maybe I didn't explain clearly enough: this PR gives us mapping of wrapped types for free

From the updated README section on encoding

import io.getquill.sources._

case class UserId(value: Int) extends AnyVal with WrappedValue[Int]
case class User(id: UserId, name: String)

val q = quote {
(id: UserId) => for {
u <- query[User] if u.id == id
} yield u
}
db.run(q)(UserId(1))

// SELECT u.id, u.name FROM User u WHERE (u.id = 1)
Pretty simple implementation, just a couple of traits and an implicit conversion. Scala's a strongly typed language, let's use types to our advantage

—
Reply to this email directly or view it on GitHub.

[godenji]

but as I use value classes a lot

@lvicentesanchez exactly, got 50+ tables in a production app and definitely don't want to write implicit encoders for UserId, OrderId, etc. when I switch the backend over to Quill.

[fwbrasil]

👍

[fwbrasil]

@lvicentesanchez Do you mind if we merge this change and you test it on master?

[jilen]

👍

[lvicentesanchez]

Yes, I don't mind that :)
👍

[godenji]

@fwbrasil @lvicentesanchez @gustavoamigo @jilen looks like updating the branch requires committers to re-approve the PR? That or there's some kind of pullapprove cache that isn't getting cleared.

Otherwise, good to go for merging.

[lvicentesanchez]

👍
On 26 Feb 2016 14:24, "godenji" notifications@github.com wrote:

@fwbrasil https://github.com/fwbrasil @lvicentesanchez
https://github.com/lvicentesanchez @gustavoamigo
https://github.com/gustavoamigo @jilen https://github.com/jilen looks
like updating the branch requires committers to re-approve the PR? That or
there's some kind of pullapprove cache that isn't getting cleared.

Otherwise, good to go for merging.

—
Reply to this email directly or view it on GitHub
#199 (comment).