Hi to all with some internal knowledge of Hibernate,

Our development team has found that it will be of some serious value to us if we could use the Session.find() method to not only query from the database, but from the current Session cache.

A simplified example of the situation we need to work follows:



We were prepared to put some time and developer resources into this (i.e. we would be doing this ourselves in house). We also have an alternative solution which promises to be very painful to implement and much less neat than if the change to Hibernate we propose was implemented.

It has fallen to me to do some of the analysis for this over the next few days before we make the decision of which path to go down.

I was hoping that those of you that have had significant input in writing Hibernate could pass on your opinions of the feasability of making the above work. Is there anything intrinsic within the architecture of Hibernate that would make this particularly tricky to do? Any advice or pearls of wisdom that might make the decision easier would be much appreciated.

Thanks,
Luke.

If you are trying to avoid phantom reads, why not just flip your JDBC connection to SERIALIZABLE isolation (assuming your database supports that).

Well, it would be quite difficult to implement for HQL queries, partly because its just difficult, and partly because the HQL parser does not yet work by creating an AST. So you would have to write a complete HQL parser (and write a proper grammar while you're at it). Now, if you wrote a working HQL -> AST parser for me, you would be my best friend for ever ... but that is not trivial.

OTOH, it looks quite easy to add to the Criteria query API, but don't expect to be able to do it in 2 days. It would take me at least three, I think. You longer, presumably.

However, remember that before I would accept anything like this into the Hibernate codebase, it would need to handle not just newly saved objects, but also updated objects, and also deleted objects. Now, I don't think that there are any special difficulties added by updates that don't exist for saves, but make sure you consider this.

Hmmm... a parser for Hibernate Query Language eh? I have some experience writing compilers (AST based), maybe I could help out. Is there some sort of BNF for HQL that I could take a look at? I suppose I could try to figure it out from the docos.

Here is the best I can give you ... probably broken, since I never tested it...


http://www.hibernate.org/Documentation/HQLBNF

I was looking for this BNF the other day. I could not find the link from the documentation page. Maybe a stupid question but where is the link ? Can we also check to see what else has been dropped off the radar (if anything).

It's linked on the "Community Area" index page. As far as I know, nothing has been lost, all is linked and (mostly) good.

Hi all,
Thanks for your response so far.

We've been digging through the Hibernate code to see just how difficult this is going to be, and are unfortunately getting to the stage where us doing this is becoming less and less likely.

The reasons for this are that the two different broad methods we can think of to implement this are both quite hacky, complex and probably slow. I'll quickly describe them both as food for thought:

1. Running the HQL command as normal on the database, then inserting all records that are not part of the database into the list of retrieved records. This is OK in the most simple of cases, but it quickly becomes over complex in cases such as:

In this case, inserting a Foo type object that hasn't been commited yet would require a further database query to get all bar.name's before being able to decide whether the uncommited Foo belongs in the list. Add in a complex set of left joins and it is possible that each HQL query may require several more database queries. To us this looks too slow and complex to be of too much use, especially as we are often dealing with database tables with up to a few tens of thousands of rows.

2. The other solution thrown about was to commit any object that was currently in the Session, but not in the database in a new Session, execute the query on this new Session and then roll back the transaction. Adding the extra db transaction is not very appealing to us, and then there is the issue of locking the database while this occurs (so that no other concurrent db user gets the temporarily added records).

There are more holes with these approaches that many of you will be able to pick quite easily.

As I mentioned in my first post, being able to do this change will provide an elegant solution to a fairly large problem we have in our app -- but if the cost is too high we will need to put our developers on another uglier, but quicker, solution. If anyone can provide some guidance or suggestions on how to overcome the above problems so that we can justify making the modification to Hibernate please do post (or email if prefered).

Thanks again,
Luke

Yes, good point, in cases like this it would actually slow the query down a great deal, wouldn't it. Interesting. This is a problem with the whole *notion* of queries done on the session cache, not just a design problem.

However, a case where it could work effectively is for queries with no joins. It is also easy to implement in this case ;-)

Thanks. I've started working on an HQL grammar, and started a new topic in 'Misc' for this.

This should be discussed in the development list.

Oh, okay "my bad". I guess I should subscribe to the development list. :")

:)