The first mistake I have was start coding too fast. I started following a tutorial, but I confess that I focused too much on code, an little on the theory. Following that tutorial I set a OneToMany relationship between an user and his accounts. Somehow, I thought that the account list in the user side would get filled automagically, driven by the annotations I was using. As the accounts got dropped from the database when I deleted an user, I thought everything was alright, and I didn't think about too much.

Yesterday, doing some tests on the category entity, I found that in a child-parent relationship, the child didn't have its parent category updated when I deleted that parent category. In the database I had set "ON DELETE SET NULL", and looking at the database while performing the tests showed that it was working there. But Hibernate didn't seem aware of that behavior, and the link to the old parent category still appeared in the child. That led me, after some tries, to understand how cascading was supposed to work and how badly I was using it. I had several cascading annotations in the ManyToOne side of some relationships, which meant that when I made a change on the many side, the other side was getting affected. And that wasn't the behavior I was expecting!

I went to the documentation to learn how should annotations work, and what did they mean according to the context they were used in. After that, I removed most of my annotations, and made some changes, in the update and delete methods in my DAOs to spread the changes when that was needed.

Now, an user has a list of accounts. When an account is created, it sets a reference to the user who has it. And makes that user add it to his account list. When an account is deleted, it makes the user remove it from the account list. As the account operations have a reference to an account, Hibernate is responsible to update that reference.

The categories behavior is similar. When a root category is created, it creates an empty list of child categories. When you add a child category to a parent category, you add that child to his parent list. When deleting the parent, you have to go through the list, updating all the references in his children. When deleting a child, you have to remove it from his parent list.

After these changes, everything is working now. I know that some of the tests I've done are too bound to my interpretation of the behavior they have to show, and so they may be wrong. But at least I get rid of part of the errors I still have.

The application is getting closer and closer to an usable state, and I expect it to be running in about two or three weeks.

Today's odd error was a lot easier than the others: id to load is required for loading. Maybe not the most complete description, before you find the place it is failing, but good enough once you go to the correct line number. I was using some fields in an Action which I haven't initialized yet. D'oh!

I thought it would be easy: change the Category entity, check the on delete and on update constraints in the database creation script, refactor and go on.I also had in mind some refactor in my JUnit tests: I have just two cases, one for each Facade, and several methods inside, for each of the actions in that facade. But as the application was getting larger and larger, I decided to have one JUnit case for each Facade Method, with several test methods for each of the possible scenarios I can think of.

So I was there, refactoring tests, moving some code to the setUpBeforeClass and tearDownAfterClass methods, when everything started to break:

deleted entity passed to persist and detached entity passed to persist. After some research in Google, I understood what could be causing the second error, so I solved it:

I was using an entity in a call to persist which had been "left" unchecked by the entity manager (detached is the word, but I didn't know it). I got the entity again by invoking find, and passed it fresh, and it worked out.

But the first problem was harder. Google didn't shed any light on me (apparently), as everything was about deleted entities which were still referenced by others related to them. I didn't have any entity left: this was happening in the tearDownAfterClass method, and I was removing the entities left after the test. And then I realized that most of the clean up was supposed to be done by cascading. So, maybe cascading tags were incorrect. I checked out my classes, and I changed some of them: putting the explicit ones instead of CascadeType.ALL. I still have to test some of the Update methods, but for today, it's fixed.

Having just one category  looked enough for me, until I realized that sometimes you may want to highlight, someway, an operation. And that could be done using tags. They should be different from categories, being a more specific way to filter operations, but making easier to develop the application core.

So, right now, this is the selected choice. One operation could be categorized or not, but should be classified in just one category. Categories, themselves, can be arranged hierarchically. And finally, operations can be tagged with multiple tags.