Updating data in SORM seems possible (even though I was told it aimed at immutable data...)

Question

I was told that SORM aims at immutable data. It's not written on the website - at least not in the main parts I was looking at, so I was a bit surprized of the rigidity of the claim. I was just aware it would recommend to do so. But maybe I was just missing something.

The examples tell you to use a ".copy(propery = newvalue)" before calling a Db.save() on the object. So thats a hint.

I was interrested in what would happen if I would just change the data and update it in the database. Strangely the following just worked fine:

case class Agent( var name : String )

object Db extends Instance(
  entities = Set( Entity[Agent]() ),
  url = "jdbc:h2:mem:hansi"
)

class SORMTest  extends FunSuite {
  test("Update") {
    // Store values in the db:
    val agent = Db.save( Agent("test") )

    agent.name = "hansi"
    Db.save(agent)
}

It produced an update statement in the database that changed the name property for the corresponding id.

Is it kind of crazy to do so? Any comments from the developers?

Answer 1

I was told that SORM aims at immutable data. It's not written on the website

It's stated plenty of times that SORM strongly follows functional programming idioms. This implies operation on immutable data-structures only.

The examples tell you to use a ".copy(propery = newvalue)" before calling a Db.save() on the object.

That's where you're wrong. The examples tell you to use .copy(..) to get an updated immutable value of the object it's called on, calling it before calling a Db.save() per se as in the following:

agent.copy(name = "new name")
Db.save(agent)

will have absolutely no effect, because, once again, .copy() doesn't mutate the object it's called on, instead it returns an updated copy of this object. So the proper use is the following:

val updatedAgent = agent.copy(name = "new name")
Db.save(updatedAgent)

or simply:

Db.save( agent.copy(name = "new name") )

But the fact is all the above has to do with SORM only as much as it has to do with functional programming in Scala in general. This is really a very basic stuff about how case classes are supposed to be used. So please do yourself a favor and introduce yourself to basics of functional programming. This will wipe out all the questions on SORM you've already had and, I'm sure, plenty of those which are comming up otherwise.

Your example works and it's supposed to, but it doesn't change the fact that it goes against the basic idioms of functional programming and as such is an unidiomatic use of SORM.