Hibernate version: 2.1.2

Name and version of the database you are using:PostgresSQL 7.4.5

Hi everyhone

Is there a way to disable transparent persistence in Hibernate ? My real issue is that we're very interesting in lazy loading functionality, but we find automatic updates on setter invocations too much transparent and dangerous...
I know we can use Session.evict() to detach objects from the session, but it'll also disable lazy loading, which is not our goal !
I searched over this forum for responses to this issue, but didn't found it yet.

Thanks
Fran

Set FlushMode to NEVER on your Session and also don't flush() it manually.

Everything works fine !

Thanks

unfortunately, i missed some bad effect with your solution... in fact, setting FlushMode to NEVER disable ALL changes to the database, which consist of setting the session readonly. my first goal was to disable automatic updates on setter calls, but not to disable all updates, inserts and deletes. i'd like to tell hibernate to update the database only on Session.update() call, and preserve save, delete and lazy loading functionalities....
is that possible ?

thanks,
Fran

You realize that session.update() does not mean "UPDATE" in the sense of an update statement. I think you are using Hibernate wrong, it manages object state. Don't think in SQL statements.

you're right. we used to have a SQL-like DAO framework before, and we decided to use Hibernate for few weeks only... but the philosophy is totally different, and i try to make it easier for developers to understand Hibernate, which is really complicated ! their main argument is that they don't know if the objects they're manipulating are associated with session or not... disabling automatic updates on setters may decrease complexity, but perhaps you're telling me that it is not possible?

You are heading down the wrong way. Instead of working against your persistence library, tech your developers what they have to know about object states. Its not as difficult as you think and it will save you a lot of time in the long run.

Hi,
Kind of off the topic, but close, if i know that my queries are read-only, would setting flushmode to never really help? What else can i do to reduce the overhead?

tnx.

What overhead? The overhead of "persistent instances" in memory? Then use a projection/dynamic instantiation query.

Correct me if i'm wrong, but projection queries would produce rows and columns, not the mapped objects. How can i mark my queries read only so that the appropriate read-only locks are requested from the db, and hibernate doesn't keep track of object updates (that's the overhead that i meant, unless you tell me that it's completely free).

tnx.

By using projection and dynamic instantiation queries. Please, check the documentation about this. There is currently no way to do "read only" Sessions in Hibernate, it is on the TODO though for Hibernate3.

Tnx for your response, I guess i can use dynamic instantiation, but still use my mapped object model (no harm in that, right?). My database also support select for readonly and select for update to set the lockmode. Anything i can do to utilize these keywords in queries?

This is explained in the "queries" reference doc chapter and the Query API documentation.

Thank you for the explainations, i'll keep them in mind in our future developments

Fran

A couple of clarification questions on this:

If I set FlushMode to Never on my session, AND subsequently call some mutating operations on the same session such as "save" or "delete" etc., then what would happen? Does that actually accumulate all the changes in memory without flushing them out, and the changes are simply discarded at the time the session is closed UNLESS a flush method is called explicitly before that?

Similarly, what if I started a normal "update" transaction within the session whose FlushMode is set to Never? In that case, commiting the update transaction will still flush the changes out to the database, since transaction commit implicitly triggers flush operation on the session, right?

This details is very important for my project, so an answer would be greatly appreciated.

/Jong