Leaky abstractions in JPA eclipselink

Leaky abstractions in JPA/Eclipselink
Leaky abstractions in JPA/EclipseLink

In our team we use JPA, EclipseLink to be precise. Now we start stress testing we notice something weird. The child relations of a entity are not updated if we only save the child. Probably we can prevent it by some configuration/annotation or other way, but we use an ORM to make sure we don’t have to think about these things.

Let me give you some code samples. There are two entities involved: ParentEntity and ChildEntity:

public class ParentEntity {
       
    private long id; 
   
    private List<ChildEntity> childs;

    @Id
    @SequenceGenerator ... 
    @Column ....   
    public long getId() {
        return this.id;
    }

    public void setId(long id) {
        this.id = id;
    }
    
    @OneToMany(mappedBy = "parent")
    @Column ....
    public List<ChildEntity> getChilds() {
        return this.childs;
    }

    public void setChilds(List<ChildEntity> childs) {
        this.childs = childs;
    }
} 
public class ChildEntity {
   
    private long id; 
   
    private ParentEntity parent;

    @Id
    @SequenceGenerator ... 
    @Column ....   
    public long getId() {
        return this.id;
    }

    public void setId(long id) {
        this.id = id;
    }

    @ManyToOne
    @JoinColumn ...
    public ParentEntity getParent(){
        return this.parent;
    }

    public void setParent(ParentEntity parent) {
        this.parent = parent
    }

} 

Furthermore we have a ParentEntityRepository object manages access to the entities.

public class ParentEntityRepository {
   
    @PersistenceContext  
    private EntityManager em;
    
    public ParentEntity save(ParentEntity parent) {    
        return em.merge(parent);
    }

    public ChildEntity saveChild(ChildEntity child) {
        return em.merge(child);    
    } 

    public List findParents() {
         return em.createQuery("select parent from ParentEntity parent").getResultList();
    } 

Some times we need to add a new child to an existing parent. The easiest way to do that is to create a child set the parent and save the child.

    ...
    @EJB
    ParentEntityRepository repos;
    
    public void addNewChildToParentAndProcess(ParentEntity parent) {
        ChildEntity child = new ChildEntity();
        child.setParent(parent);
        repos.saveChild(child);
      
        process();
    }

    public void process() {
        List parents = repos.findParents();  
        //display all parents including children
    }
    ...

The problem now is that the new child is not added to the parent in our front-end, but in the database the child is added and has the correct parent attached to it. After some time (EclipseLink cache expiration?) the results are correct.

I think this is really disturbing. You use a ORM to have an abstraction from your data layer, but it seams it’s a leaky one. I can’t remember that Hibernate has the same behavior, my memory might be misleading me though ;-).

P.S. The solution is to add the child to the parent and then save the parent, but I don’t think that should be the case.

Edit:
Coen Damen pointed me to the EclipseLink F.A.Q. with another solution by calling refresh() on the parent. Still I think it should be managed by the framework as I don’t want to think about database relations and when to refresh an entity.

Coderetreat in December solves quine problem in March

You saved the world - space invaders quine
You saved the world - space invaders defeated

Yesterday I spoke to @MMz_ about my Space invaders quine. As is was a general meeting and a lot of people attended we didn’t have time to look into the solution properly. So I promised him to explain the details on a later moment. I think more people would like to know how the technical solution works so I decided to write this blog.

The first step in the program is to read the “field”. The last statements in the file are:

field =
"
#####################################################r
#01   **********                                     #
#02   **********                                     #
#03   **********                                     #
#04   **********                                     #
#05                                                  #
#06                                                  #
#07                                                  #
#08                                                  #
#09                                                  #
#XX                       %                          #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"

invaders =  SpaceInvaders.new(field)
invaders.next_move

Basically the space invaders field is initialized and next_move is called.

Below you can find an simplified version of the next_move code.

def next_move
	move_invaders
	calculate_new_field
	move_darts_up
	calculate_new_field
	player_shoot
end

So the invaders are moved, a new state of the field is calculated, the darts (bullets/lasers) are moved upwards, a new field is calculated and finally the player puts a new dart in the field as the shot is calculated.

While initializing the SpaceInvaders class the field is pre-processed. In order to move the invaders and the darts it is easier if the input field is split into two separate fields. One containing only the darts and another only containing the invaders. This makes moving each type of objects a lot easier.

The darts field is a String that contains line-ends, spaces and darts (i). To move all darts up basically the only thing that has to be done is remove the first line of the String and add a new line at the bottom. In code this is like:

def move_darts_up
    lines = @darts.split(/\n/)
    lines.map! {|s| s = move_line_up(s)}

    #add extra bottom line 
    lines.insert(9,"#09                                                  #")
    
    #remove top line
    lines.rotate!(1).pop    

    result = ''
    lines.each {|line| result += line + "\n"}
    @darts = result;
end

The next step is calculating the resulting field. The top line of the field doesn’t change neither do the bottom lines starting with the line #XX ……. So these lines are just copied. For the middle part both the dart field and the invaders field are overlay-ed. For each position in the field if a dart and a invader are found on the same position they both are removed from the resulting field. The actual overlay code looks like this:

def calculate_new_char(dart,invader)
  if(invader == ' ' ) 
   return dart
  elsif (dart == 'i')
    return ' ' 
  else
    invader
  end
end

Next step is to move the invaders. Initially the invaders move right. But if the wall is “touched” they move one line down. After the move down the invaders move left till the left wall is “touched” resulting in an “s”-like pattern.

The current direction of the invaders should be “remembered” by the source code. If you look at the last character of the first line in the field you see the “r”. This is the current direction.

Moving the invaders right is actually quite easy. The most right character of the field is certainly an empty place, otherwise the wall was “touched” and the invaders move down. If each line in the invaders field is put in an array of characters and the resulting array is rotated the invaders are moved right. The only thing left is to make a new string of that array. In code this looks like:

def move_line_right(line)
  if line.match(/^(#\d\d)(.*)#/)
    return $1 + $2.split(//).rotate(-1).join + '#'
  end
end

Moving left works similar only rotating 1 position to the other side. Moving down is similar to moving darts up. One extra thing for moving invaders down is to detect if any invader reaches the “player line”. If this happens the user failed to defend the earth.

Last step is to let the player shoot. When running the program is is possible to supply a number as argument. This argument is used to determine where the player shoots. Shooting is just replacing the player line with the new version.

Last step is to make the code a quine. I simplified the next_move method shown above. There are some extra steps. These steps are to see if the player has won/lost and also to calculate & write the next state of the source code. At this moment the new field is calculated. So the “only” thing left is some String manipulation in the source code to replace the old field, with the new field. With a regexp that is quite easy. The code looks like this:

  input.gsub!(/(\r?\n#####(l|r|.|\n|\r)+?#######\r?\n)/,@field)

Now you’ve seen my solution some closing thoughts. The first steps into my solution was moving the invaders right. Initially my solution was to read the field and use a regexp to match a line with “*” in it and remove the last space character and adding a new space on the left. Getting this to work is not really difficult. After implementing moving down and moving left I decided to introduce darts and to move these darts up. I couldn’t find out how to get that working. After thinking about it for half an hour or so I decided I couldn’t fix that. I stopped coding at that moment to come back at a later moment. As someone put it before:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

The morning after I suddenly had an idea how to solve it. I remembered that during the global day of code retreat in December some people solved Conway’s Game of Life by overlaying multiple copies of the initial state. I’m convinced that attending the global day of code retreat helped me create this quine. Waiting a day to get the solution is for me just like the “Thoughtful walking” technique described in Pragmatic thinking and learning.

P.S. If someone else is trying to make a quine and write it to a file, please make sure you don’t overwrite your source file until you’re ready to release your solution. As you are replacing things in the original source file and you make a mistake (I know you don’t make mistakes), you loose the original version. It happened to me several times. Thank got I had Git & committed a lot. The full code can be found on GitHub.

Devnology codefest: Space Invaders quine

You saved the world - Invaders defeated
You saved the world

As a participant in Devnology Code Fest Space Invaders I knew immediately what the solution should be.

Some time ago I visited the Hot or Not Software Craftsmanship session by @KevlinHenney. In that session Kevlin introduced me to the principle of a quine and showed some examples. One of the examples was the Qlobe – a quine that shows a globe in the source code that rotates 45 degrees when executed.

So my contribution should be a space invaders quine. Furthermore my ruby skills need some practice so it will be a ruby space invaders quine. This is also a good excuse to finally finish reading Programming Ruby: The Pragmatic Programmers’ Guide. Below you a few possible game states are shown, the full solution can be found at GitHub.

"
#####################################################r
#01     **********                                   #
#02     **********                                   #
#03     **********                                   #
#04     **********                                   #
#05                                                  #
#06                                                  #
#07                                                  #
#08                   i                              #
#09                   i                              #
#XX                   %                              #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"
"
#####################################################r
#01                 *********                        #
#02                 *********                        #
#03                 *********                        #
#04                 **    **                         #
#05                   i                              #
#06                   i                              #
#07                   i                              #
#08                        i                         #
#09                        i                         #
#XX                        %                         #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"
"
#####################################################r
#01   **********                                     #
#02   **********                                     #
#03   **********                                     #
#04   **********                                     #
#05                                                  #
#06                                                  #
#07                                                  #
#08                                                  #
#09                                                  #
#XX                       %                          #
###0        1         2         3         4         5#
###12345678901234567890123456789012345678901234567890#
######################################################
"

invaders =  SpaceInvaders.new(field)
invaders.next_move
" ____  ____ ___ ___   ___       ___  __ __   ___ ____
 /    |/    |   |   | /  _]     /   \|  |  | /  _]    \
|   __|  o  | _   _ |/  [_     |     |  |  |/  [_|  D  )
|  |  |     |  \_/  |    _]    |  O  |  |  |    _]    /
|  |_ |  _  |   |   |   [_     |     |  :  |   [_|    \
|     |  |  |   |   |     |    |     |\   /|     |  .  \
|___,_|__|__|___|___|_____|     \___/  \_/ |_____|__|\_|


game has been reset for next try
"

Adjust design to get green bar

pragmatic programmer
pragmatic programmer
pragmatic programmer

A while ago I read the pragmatic programmer. In the book are many tips listed. In the back of the book there is an tear-out card with all the tips collected. As I’m working on different locations all the time I rarely look at the card. The tips however seem very useful to me. Therefore I created a small Google App engine application that sends me a random tip every day. TDD-ing my way through the requirements I now get a tip every day. During the development I ran into one little problem with stubbing my randomizer method.

For the unit-tests testing sending the mail I needed to stub the random result to give a certain result. So I could check that the rest was working. For mocking & stubbing I use Mockito. The normal way you stub a method in a class is to create a mock version of the class and use the when-then pattern as documented over here. The problem I had was however that the method getting the random result was part of the class under test. This resulted in the test failing because sending the mail was never being executed as it was a Mock. Please see the code below:

public class TipRepository {
    ...
    public String randomTip() {
        return tips[getRandomNumber()];
    }

    private int getRandomNumber() {
        return (int)Math.round(Math.random() * (tips.length-1));
    }
}

And the test looked like this:

public RepositoryTest() {
    @Test
    public void randomTestShouldReturnExpectedTip() {
        TipRepository tipRepo = mock(TipRepository.class);
        when(tipRepo.getRandomNumber()).thenReturn(0);
        assertEquals(tipRepo.randomTip(),"sometip")
    }

}

Please note that I use TestNG as testing framework. In TestNG the expected and actual result are reversed if you compare it to JUnit.

So all my tests where failing. In order to get a green bar again I need to adjust my code to be able to test it. After a lot of thought I created an extra class that contains only the randomizer method to pass it into the repository as a dependency.

public class TipRepository {
    private Randomizer randomizer;
    ...

    public TipRepository(Randomizer randomizer) {
        this.randomizer = randomizer;
    }

    public String randomTip() {
        return tips[randomizer.randomNumber(tips.length-1)];
    }
}
public class Randomizer() {
     public int getRandomNumber(int maxValue) {
        return (int)Math.round(Math.random() * maxValue);

    }
}

And the test now looks like this:

public RepositoryTest() {

    @Test
    public void randomTestShouldReturnExpectedTip() {
        Randomizer randomizer = mock(Randomizer.class);
        TipRepository repository = new TipRepository(randomizer);
        when(randomizer.getRandomNumber(2)).thenReturn(1);
        assertEquals(repository.randomTip(), "some tip");
    }
}

Of course you can argue that getting a random number is not the responsibility of the Repository and that therefore the new design is better. But in the old situation the random number was coming from the Java API. Therefore it was not a responsibility of the Repository either. I’m happy to have a green bar now, but I don’t like changing the code just for the tests to be passing. Please let me know your thoughts in the comments or via Twitter.

Review: The clean coder

Cover of the clean coder
The clean coder

Last week I finished reading The clean coder written by @unclebobmartin. The book’s subtitle: “A Code of Conduct for Professional Programmers”, summarizes the book quite good.

Throughout the book @unclebobmartin tells about his own experiences during his career. Also he illustrates the points he wants to make with excellent example discussions between (project) managers and developers. These example stories are quite entertaining and make the book easy to read.

The first few chapters discuss how a professional developer behaves as a person. It’s all about managing expectations & making sure that you’re in the right state to do your job. After that some practices that improve the quality of your work are introduced. Examples practices are TDD, testing in general and estimation. The last chapters discuss how to behave in a team. A embarrassing paragraph in these chapters is called “Degrees of failure”. In that part @unclebobmartin basically explains how the education system fails to educate software developers.

It’s a nice book to read and has nice suggestions how software developers can improve their work and become craftsmen. However many of these tips are not new to me. They can be found in the enormous blob of blogs about agile / lean / etc. development. Only the estimation chapter gave me some real new information. Because the book is written in @unclebobmartin’s distinctive style I still recommend the book. The pragmatic programmer is a different league though.