Right now Notes/Attachements is a cross-cutting concern: Notes are attached to project, iteration, story and task (something tells me I forgot some...).

The problem is a pure OO/SQL impedance mismatch:

We do have an inheritance view of each project element since they all can be annotated. Any project element implements the interface Annotable (NoteAttachable right now until we rename this bad name... ;-( ). XPlanner keys in into that marker interface and performs the relationship cleanup within the base Repository.

Unfortunately on the persistence side there isn't a mechanism to deal with polymorphic relationship (note->annotable). At the core of this evil situation is our usage of cascades to delete container elements and their items. Since the clean up happens within the database, XPlanner cannot enforce the note cleanup. You delete a project and automatically all its containing elements get deleted automagically because of cascades. Alas, we cannot do this with note and attachements. The project notes will get cleaned up but not the notes of its iterations, stories...

To make matters worse, there isn't any simple mechanism in RDBMS persistence world to do something similar. At the minimum we could create an inheritance hierarchy with a table per class (even abstract) in order to have referencial integraty and more importantly cascading delete!!!

Attachements are not deleted right now because on "continue" we do not want to have 2 copies of the same attachment but rather share the same one. We implemented a reference counting mechanism that is flawed for a reason that escape my tired mind at the present moment :-P

Anyway, it is my uneducated hope that the extendable lifecycle mangement of hibernate 3 will allow us to solve these defficiencies in a very elegant and simple way (listen to any project element deletion and implement the right note/attachement clean up). This obviously is based on the assumption (hence uneducated hope) that hb would know more about the cascades that we would in xplanner. If it isn't the case, we would just have to fix our current implementation).