I've got some persistent Objects, duh. After each update, if the Object's data values are not valid, a set of Problem objects are created and attached to the Object. All well and good, but here's the little twist. For various reasons, the Problem objects must not be deleted when resolved, but rather simply closed. However, in my application code, it is very seldom that I am interested in any but the open Problems, so it seems silly to always be iterating over the Problems and continuing on closed Problems.

I can easily use hibernate filters on the problems collection to efficiently skip closed problems, but then I've got hibernate-specific code hanging out in my business logic where ideally it would not belong. I've idly thought about giving my Objects two Problem collections, one for open, one for closed, and just move the Problems from one to the other when they're resolved. Would that be the best way to do it or is there another design pattern you might recommend?

Cheers, y'all.

what about advanced hql or collection filter ?

Sure, either of those is quite effective, but the problem is that it embeds some hibernate-specific stuff in my business logic. I want to avoid that to the greatest extent possible. I almost exclusively traverse the object graph in my business logic.

isolate this into a DAO or helper layer interface


do this can help?:



http://www.hibernate.org/hib_docs/refer ... tions.html

Thanks for the tips. I myself don't really like the DAO pattern and am not using it on this project. The arbitrary where clause would be a way to do it if it were possible to have hibernate map two collections with different where clauses under the same parent.

I think I'll probably end up just mapping two different collections with different association tables for open and closed problems.

You could do this easily in Hibernate3 with its new dynamic filter stuff.

Cool. I look forward to checking it out.