Monday, 30 June 2014

Hibernate and Caching

One of the major problems of debugging, is that sometimes there are bugs, but they only happen some of the time1.

This makes it hard to fix, unless you can spot the pattern required for the bug to appear.

The Problem

My colleague at work had such a one.

Sometimes the software threw an exception and complained that the table in the database did not actually exist. Sometimes the program provided the data required, and went merrily on its way.

It's crazy for a database table to exist only some of the time.

It made sense in this case that the table didn't exist. Because that table wasn't in the database. The Entity was purely used as a 'View' and several methods gathered the information to load an instance of the Entity.

The Explanation

Hibernate provides caching, meaning that a lookup by Identifier for an Entity returns the Entity from the Cache without hitting the database, if the Entity has been loaded already once.

Turns out our method, which loaded an Entity, totally didn't work at all! It just happened to return a Cached instance in some cases without problems.

A cached instance that was loaded by using another method that did not rely on findByIdentifier (for example via "select new Constructor()").


[1] The Kingdom of Transformation
[2] Hibernate - Object Identity

Wednesday, 25 June 2014

Scala: π and Streams

I finished my course of "Functional Programming Principles in Scala" at coursera1.

Go me!

Wikipedia3 has an article on how to compute π. The series is provided below (using MathML2, which might not work as it should in some browsers) originally proposed by Srinivasa Ramanujan.

1π=229801 k=04k!1103 + 26390kk!43964k


To compute the equation above, I'm going to use BigDecimals5 and I shall have to define some math operations.

So let us start with the Scala version of Factorial, which is equivalent to the Java Version of Factorial of my earlier blog post4.

Notes on Scala

I really like how Scala almost always infers the correct type automatically and can redefine common math operators for classes like BigDecimal. When dealing with BigDecimals, this is great. It makes it ideal for DSL, Domain Specific Languages. Compare the factorial calculation with BigDecimals below in Java and Scala for example:
return factorial(accumulator.multiply(n), n.subtract(BigDecimal.ONE));

factorial(accumulator * n, n - 1)
I also like the fact I can define Worksheets in Scala, that are evaluated by the IDE upon saving, printing the results at the end of the line. For mathematicians it's the computerized equivalent of paper napkins in Restaurant, only better.

Square Root

There is a Square Root function available in the math library of Scala6, but it doesn't work with BigDecimals (def sqrt(x: Double): Double).

A way to compute a square root is using "Heron's method"7. That one can also be defined using recursion, similar to the Factorial above.

It is quite obvious that there is a problem in the code above. It is recursive, and the recursion never stops, leading sooner or later to a nice StackOverflow Error.

Some ways to solve it is to limit the number of iterations, or stop once the precision is adequate. An example of the first is seen below, where the number of iterations is 100.

But, it is slightly ugly. During the course, I learned that Scala tries to adhere to the Rules of Mathematics more than to the Rules of Programming. We should be able to define a pure function, without having the computer explode.


Scala has several ways in which functions get evaluated:
strict evaluation
Functions get evaluated immediately. For normal parameters and val definitions. This is the default.
lazy evaluation
Functions get evaluated when the function is called for the first time, and the value is cached and not recomputed.
by-name evaluation
Functions get evaluated each time the function is called. For "def" functions.
Streams are a way of creating data structures that are not evaluated immediately. An example of the use is shown in the following implementation of squareRoot:
The above example, barring the Stream calls, is equivalent to the first example of the squareRoot. Thusly we have defined something much more equivalent to an infinite series.

As you can see squareRoot(2) will get evaluated to Stream(1, ?). So only the head is evaluated, the first guess, and the rest is deferred, visible by means of a "?".

In order to force the evaluation of the rest, you can try for example squareRoot(2).take(5).toList, where take creates a new Stream that has a fixed length of 5. The toList forces the evaluation, as a list only knowns strict evaluation.

Now we should have all the ingredients to implement the equation visible at the top of this blog.

Computing π

In the example above, the actual number of terms in the series is 5, which is sufficient as the series converges extraordinarily rapidly to π.

In the example above, we are also using our new squareRoot function, this time with the number of iterations set to 120.

Of course, actually producing the exact result is impossible, but in Mathematics, I find that in most cases the definition is the important part, in order to reason about it.


[1] Coursera - Functional Programming Principles in Scala
[2] MathML
[3] Wikipedia - Approximations of π
[4] Recursive Factorial in Java
[5] scala.math.BigDecimal
[6] Scala Math Package
[7] Wikipedia - Methods of computing square root
Wikipedia - Arbitrary precision arithmetic

Wednesday, 11 June 2014

Scala Collections

Great, I have just been overthinking myself.

I have the following setup:
val nums = List(('a', 2), ('b', 2))
I wanted to convert this List of Tupels into a Map of the kind Map( a -> 2, b -> 2). So, off I went...
val mapping1 = nums groupBy (_._1)    // mapping1  : Map[Char,List[(Char, Int)]] = 
                                      //    Map(b -> List((b,2)), a -> List((a,2)))
val mapping2 = => (x._1, x._2.head._2))
                                      // mapping2  : Map[Char,Int] = Map(b -> 2, a -> 2)
Well, this is hardly convenient.

If you have a Tupel in Scala, like val t = (5, 2), you can access both values using the syntax t._1 and t._2.

Here are the steps:
  • groupBy makes a Map, where the key is the first Value in the tupel, with the original tupel assigned as the value.
  • then the mapping, it takes each item from the map and transforms them to something else. In our case, it transforms (a, List((a, x))) into (a, x) by:
    • leaves the first value of the tupel unchanged, i.e. a
    • takes the head of the List((a, x)), i.e. (a, x)
    • grab the second value from the tupel (a, x), i.e. x
Well, to make a long story short, it seems I could have simply sufficed with:
nums.toMap     //> res6: scala.collection.immutable.Map[Char,Int] = Map(a -> 2, b -> 2)