Example: in my data model I have a many-to-many relationship between Role and Order, via a Permission table that have an extra column for the name of the permission. E.g., the 'admin' role can view and modify orderA, but only view orderB. The permissions' names are, of course, 'view' and 'modify'.
In classic db design fashion, the foreign key from Permission to Order would have an on-delete-cascade clause to prevent dangling permissions. However, I use hibernate with second level cache, and it is required that all the permissions objects be in the cache, so when deleting an order, I rely on hibernate to automagically delete the permissions as well and evict them from the cache before deleting the actual Order.
This is all working fine, except that I feel the data model is "polluted". The role and permissions are part of the meta-data, not an intrinsic part of the model. They are dealt with in a security interceptor (acegi), and always accessed from the Role's side of the relation.
In effect I never use the permissions directly when using the Package object (or other objects, which I omitted for brevity), but I still have to deal with them, because they appear as a field member of Order class, in the hbm, and they affect the performance of some queries.
So my question is: I am thinking of decoupling the permissions from the order, and was wondering what is the best strategy to handle deletions of Orders? Currently I am thinking of two options:
- in my dao/service layer, have an event listener listen on deletions. When an order is deleted, access the permissions via the role (like the security filter does) and delete them just before deleting the actual order. Since the code runs in a transaction, I am not concerned about data corruption in case of an exception.
- Use hibernate interceptor. I haven't used those before, and wondered what's your opinion about them? Is this a valid use case for interceptors?
Do you think either of these alternatives is viable? or should I just stay with the current model?