3

So as I am reading the Play for Scala book, I came across something odd that was explained in the book. This is the relevant snippet:

There's something strange going on, though. If you're using immutable classes—which vanilla case classes are—you might be worried when you discover that Squeryl updates your object's supposedly immutable id field when you insert the object. That means that if you execute the following code,

val myImmutableObject = Product(0, 5010255079763,
  "plastic coated blue", "standard paperclip, coated with blue plastic")
Database.productsTable.insert(myImmutableObject)
println(myImmutableObject)

the output will unexpectedly be something like: Product(13, 5010255079763, "plastic coated blue", "standard paperclip, coated with blue plastic"). This can lead to bad situations if the rest of your code expects an instance of one of your model classes to never change. In order to protect yourself from this sort of stuff, we recommend you change the insert methods we showed you earlier into this:

def insert(product: Product): Product = inTransaction {
    val defensiveCopy = product.copy
    productsTable.insert(defensiveCopy)
}

My question is, given that the product class is defined like this:

import org.squeryl.KeyedEntity

case class Product(
    id: Long,
    ean: Long,
    name: String,
    description: String) extends KeyedEntity[Long]

Database object is defined like this:

import org.squeryl.Schema
import org.squeryl.PrimitiveTypeMode._
object Database extends Schema {
    val productsTable = table[Product]("products")
    ...

    on(productsTable) { p => declare {
        p.id is(autoIncremented)
    }}
}

How then is it possible that a case class declared as val can have one of its fields changed? Is Squeryl using reflection of some sort to change the field or is the book mistaken somehow?

I am not able to run the examples to verify what the case might be, but someone who has used Squeryl can perhaps give an answer?

smac89
  • 39,374
  • 15
  • 132
  • 179
  • It's not the case class itself, it's the `table` generic which is declared as `val`. It specifies the rules of accessing the objects stored in that table (which are indeed represented as case classes). – Ashalynd May 04 '17 at 23:17
  • @piet.t Lol yes you're right. I didn't think about it that way – smac89 May 08 '17 at 07:58

1 Answers1

0

You can check the definition of table method for yourself:

https://github.com/squeryl/squeryl/blob/master/src/main/scala/org/squeryl/Schema.scala#L345

It's a generic function which does use reflection to instantiate the Table object bound to the given case class. Functions are first-class citizens in Scala, so they can be assigned to a val just like anything else.

The last fragment is also an asynchronous function, which maps a given argument to some modification defined for it.

Ashalynd
  • 12,363
  • 2
  • 34
  • 37