Hibernate version:3.1.3

When you apply a filter and load an entity, the filter is not applied. Obviously it's not a bug, it's explicitly written in the code in the EntityJoinWalker class.
But I think it's not very consistent. Let's take a pretty basic example :

I define 2 workspaces, the filter expresses the choosen workspace.

When I apply a filter to choose the workspace 1 and I query some entities, Hibernate returns entities only from workspace 1. Ok.

If I load an entity with its id, the filter is not applied, why? Suppose a user alters the id in the http url, then he could easily load an entity from workspace 2 whereas the filter for workspace1 is applied. Applying truly the filter on the loading could allow to return nothing, as expected.

Please give me a feedback.

Richard H.

get/load are for when you know what you're doing: you've validated the id, or whatever. If you have a filter that you want applied to a get-by-id, use HQL or Criteria to simulate get/load:
There is a definite upside to allowing unfiltered gets/loads: it allows you do checks against out-of-filter objects (e.g. if certain types of your objects have to be unique across all workspaces, your filter would prevent you from looking in other workspaces to implement this...).

I'm rather suprised by your point of view. First, I'm not in search of a workaround, besides executing a query (hql/criteria) to load an entity by pk has many drawbacks compared to loading an entity (cache, ...). No no I wanted to talk about of general concept.

Don't you sincerely believe that when you apply a filter, you expect it applied *everywhere* without managing specific behaviors by default ?

Your definite upside is a good candidate. My vision is the following one. I apply a filter to choose a specific workspace, and when I need to ensure the uniqueness of a name among every workspace, I disable the filter, execute my query (btw not a load), and if needed, reenable the filter to come back to my intial workspace. Is it not more logical ?

My 2 cents ... But if developpers don't join my point of view, it should be neverthless possible to add an option (in hibernate.cfg.xml) to let the final users choose ...

Thank you for having paid attention to my previous mail.

Richard H.

Filters apply to searches. HQL and Criteria are examples of searches. get/load is not a search: you already know what you're looking for, you just want to fetch the object. I'm of the opposite opinion to you: get/load should always bypass all special cases and rules. You're telling hibernate that you know exactly what you want, go get it, don't even think about it.

It's not that long since filters were introduced: before that, we had to do it all in business logic. IMO, business logic is where this sort of thing belongs: the only good reason to add support for filters is that the DB servers provide this functionality, and can do it faster and more reliably than my code (assuming that they're willing to spend more time testing their software than I am mine :).