db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vandahl <thomas.vand...@tewisoft.de>
Subject Re: silent db hit for associated objects
Date Tue, 16 Aug 2005 14:05:25 GMT
Thomas Fischer wrote:
> On Tue, 2 Aug 2005, Henning P. Schmiedehausen wrote:
>> Thomas Fischer <fischer@seitenbau.net> writes:
> Hm, personally, I always use torque.objectIsCaching = true. The reason 
> is as follows: In most applications, I need transaction safety. Then, I 
> like to separate the application into a data accesss layer and the 
> presentation layer. But the presentation layer should be able to 
> retrieve associated objects, in the bookstore example this would be e.g. 
> to be able to ask a book for its author. If I want to make this 
> transaction safe and would have set torque.objectIsCaching to false, 
> then I would have to pass the database connection to the presentation 
> layer, which is not what a presentation layer is about.

If I use the getXXX methods without a connection parameter, the expected 
behaviour from my point of view *is* a DB-hit. It is more questionable 
whether the implicit caching of the collections or related objects is a 
good idea at all. It hurts especially when using managers.

I guess that getXXX(Connection con) would be a good extension anyway, 
because it makes the set of methods more logical. This way, you can 
always collect your data in a transaction and provide it to the 
presentation layer in the context separately (we talk Velocity here, 
don't we? :-)

>>> 3) add a generator property torque.silentDbFetch, which is true by 
>>> default.
>>> If set to false, the getXXX() methods without arguments will not 
>>> access the
>>> db silently, but return null if the associated objects has not been read
>>> yet. Also, the method does not throw a Torque exception any more 
>>> (which is
>>> the main reason why using these methods is more convenient than
>>> getXXX(boolean silentDbFetch) with silentDbFetch set to false).

Personally, I don't see that you gain much with this. As I understand 
it, this means that you need to prefetch all related objects in the 
business code in a transaction like

	Book b = BookPeer.retrieveByPK(id, con);
	context.put("book", b);

and then use


in the presentation layer. Is that the case? I consider this difficult 
to read. You need to know that there is something cached under the hood 
to understand what's going on here...

I kindly ask you to sleep over it again.

Bye, Thomas.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message