12

I'm currently programming in Scala, but I guess this applies to any functional programming language, or rather, any programming language that recommends immutability and can interact with a database.

When I fetch data from my database, I map it to a model data structure. In functional programming, data structures tend to be immutable. But the data in a database is mutable, so I wonder whether or not my model should be mutable as well. In general, what would be a good and well-accepted practice in such a case?

Following Scala courses by Martin Odersky on Coursera, I remember he said something like:

It's better to use immutable data structures, but when you want to interact with the real world, it can be useful to use mutable data structures.

So, again, I wonder what should I do. As of now, my data structures are immutable, and this is leading to a lot of boilerplate code when I want to update a record in my database. Would using a mutable model help reduce this boiler plate?

(I already asked a similar question which was quite specific to the technologies I use, but I wasn't satisfied with the actual answers, so I've generalized it here.)

Community
  • 1
  • 1
Sebastien Lorber
  • 89,644
  • 67
  • 288
  • 419
  • 2
    Please if you vote to close this question, tell me why. If it was already answered, give a link or something. – Sebastien Lorber Oct 21 '12 at 00:58
  • +1 I think this is a fine question. Also, you mention that the immutable model is causing boilerplate, so perhaps you should just try the mutable model. Perhaps make a quick prototype and see how it affects the design. :) – Miguel Oct 21 '12 at 03:19

3 Answers3

6

Why is a database mutable? Is it a fundamental nature of databases to be mutable? The relational model and using it as a persistence store for your application data might steer you towards this conclusion, but it may not be a fundamental property.

Given that you may have other options such as storing a new version of your data when you update it, perhaps the premise of the question is undermined somewhat. Perhaps, even if you do have a 'mutable' database, you still need to provide a new value for the update function that is separate from the old value – consider for instance an optimistic lock where the update should only occur if the old value has not in the meantime changed.

In other words, the mutability or otherwise of the database should not matter at all, you are dealing with a separate domain layer in your application. If you need to ask then the answer will always be immutable. Mutability is a complexity vector that experts should only introduce as a performance optimisation when it has been demonstrated to be necessary.

Jed Wesley-Smith
  • 4,686
  • 18
  • 20
6

In the trading app I'm currently working on, almost everything is immutable - certainly the model is.

Our experience is that this has greatly simplified how we work with the model, including persistence.

I don't understand yet why things have become simpler, it just has. I need to ponder on this more. Reasoning about the code and working with it is simpler.

Yes, you need to use things like lenses but I tend to write them - a mechanical process - and move on. It's a tiny part which I am sure can be finessed.

Channing Walton
  • 3,977
  • 1
  • 30
  • 59
3

"Interacting with the real world" has nothing to do with whether you use mutable or immutable data structures. This is a furfy that is repeated all too often and it is great that you have questioned it.

While it is typically more healthy to dismiss garbage like this, you might be interested in a cursory debunking: http://blog.higher-order.com/blog/2012/09/13/what-purity-is-and-isnt/

However, I strongly recommend dismissing it and moving on.

Onto your question, you say you have boilerplate when you want to perform operations on your immutable data structures. In fact, there is very well established theory that solves this problem to a large extent. Here is a paper written about it using Scala:

http://dropbox.tmorris.net/media/doc/lenses.pdf

Hope that helps.

Tony Morris
  • 3,045
  • 2
  • 29
  • 17