Hibernate version: 2.1.4

I tried something today and just want to submit it to everyone to check if it can be useful.

You see, I really like static queries that we define in hibernate using the <query> tag. I tend to avoid dynamic queries unless there is no way I can escape them.

But today, a developer need appeared. They need to add a security filter. Some users can work on only given data. For example a trader can book a deal only on his trading account so all deal we show him are on this account.

It appeared to me that I will need to copy this where clause in a lot of our static queries. In fact, the security filter is some kind of "query aspect". If I select trades, I need to filter them by the user trading accounts.

Right now, the idea I have to do this was to keep my queries static and without the filtering clause. Then I do this:



They cast to SessionFactoryImpl is ugly but otherwise it works. The aspect part could be to add this close each time a query is done on the trade table for instance.

Does someone have a better idea? I should I do that? If it's good, should we have getNamedQuery defined on the SessionFactory interface?

Thanks,
Henri

sounds like yu would be very interesteing in Hibernate3 filter mechanism ;)

I just read to complete specifications. Yeah... that's exactly what I need. Sad that I can't switch to hibernate 3. It won't be released before us going to production.

Do you have some suggestions to do the same in 2.1.x versions?

Apart from that, I have two questions about Hibernate 3.

First, to implement the property lazy loading, I was thinking you would do a cglib class overload to do so. But in fact it seems to be some AOP at build time. Why did you take this approach? More efficient? Less side effects?

Second, I'm really disappointed to see that there is still no lazy loading for many-to-one relationship. I though it would be included in the property lazy loading. You see, as Gavin, I rarely see any interest in property lazy loading expect the marketing part. But for many-to-one association, if can be useful. It provided a by usage lazy loading instead of by class (that the class proxy is now providing). Do you think it's something that can be looked at?

don't have a better suggestion for you regarding 2.1.x - your own solution is ok.

to do real lazy property loading we need to instrument at build time (or classloading time). If i remember correctly the resaon for this is to allow you to use your own new'ed objects.

what do you mean with many-to-one relationship not being lazy ?
If the class on the one side is a proxy'able/lazy'able it will not be loaded from the db before you access it.

Ok, let's do that then. Thanks. Can we imagine to have the method getNamedQuery accessible in SessionFactory? (I know that in Hibernate 3 the method doesn't return a String anymore) Even with the filter it might be useful sometime no?



Doh... Right, didn't thought about that. Good reason.



I mean lazy loading by usage. Let's say I have a class A. There's a many-to-one association from B to A and also from C to A.

The process manipulating B rarely use A. So I want it lazy. On the other side, the process using C almost need it everytime. I want to keep lazy false. I can't since the lazy is set on A, not on the associations.

Possibly I can put an outer-join="true" on C to patch that. But I prefer not to since I'm using level 2 caching and I don't want to do a select on table A since I probably already have the A instance in my cache.

That's why I would have want it. But in fact basically, it's beacause I want to ask myself the following question:

- Do I need to load this associated object often?

when thinking about putting lazy="true" somewhere instead of:

- Do all the classes having an association with this class benefit of having it lazy?

In the later case, I need to know the complete graph of dependencies. I also need to do regression testing all over the place to make sure I didn't broke any code using the newly lazy class.

hmm - if you can put a good argument and usecase for it then put it on as an improvement request for H3 (but i can't promise anything ;)

cool, lets see what I can do