I've read Hibernate in Action pretty much from cover to cover, and am just getting ready to get my hands dirty, but first I have one important question which wasn't answered by the text.

In my preliminary design, I have two classes/tables which will contain nothing but balances, being aged balances for the Client class and the Debt class. These will be among the most volatile tables in the system - most of the others contain static, rarely updated info or are mostly insert-only.

For this reason, in SQL terms, I had in mind to perform all the updates to these tables using SQL expressions, something like this...

UPDATE DB_BALANCE SET PAID = (PAID+ 23.45), COMMISSION = (COMMISSION + 2.35), ...

Obviously, this means bypassing the normal persistence mechanisms, and until today I had in mind to do this by making my balance classes immutable and updating them in hand-written DAO classes. But today, I came across the ClassPersister interface, and I'm wondering whether perhaps I shouldn't write my own custom ClassPersisters instead.

So that's the question. Should I write custom ClassPersisters, or is there some better way of doing this that I've missed so far?

Oh, and if I do write my own ClassPersisters, what is the best persister to extend? I presume that there is a standard default Persister, but I'm not sure which one it is.

Running Hibernate version 2.1.

TIA for any and all suggestions,
Luke

I must be missing something.
Why the heck do you need to build a custom ClassPersister? What is wrong with just running the HQL or SQL update statement?

What I want is for Hibernate to do all my reads and to maintain the lifecycle of my balance classes in pretty much every detail except when it comes time to update them. I want to do my own updating, but for preference I would like to do this when the transaction is committed, rather than having to put an extra method call after each call to Session.save().

It seems to me that the ideal way to handle this is by extending one of the existing ClassPersisters and overriding update(). Or perhaps I'm barking up the wrong tree, hence this question.

Cheers,
Luke

I don't think a custom persister is going to help you acheive what you are looking for.

BTW, Hibernate3 will have bulk update and bulk delete statements. Much more in-line with what you are looking for ;)

Fair enough, but in the meantime, I'd really like to know what my options are. I can't very well jump into version 3 when I'm just a raw newbie - I don't think you'd want me as a beta tester with no Hibernate experience at all. <g>

Cheers,
Luke

Well the problem is that you want set-based operations, whereas ORM has historically been been all about row-based operations. Hibernate is no exception to this. This is about to change, but since you have to deal with the present...

So even if you were to write a custom persister, that persister would still just "tie into" the normal Hibernate2 processing, which is row based. It has no notion of "apply this operation to many rows".

The only real option is to perform these operations outside your ORM via straight JDBC, etc.