db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject Re: silent db hit for associated objects
Date Wed, 03 Aug 2005 05:18:04 GMT


On Tue, 2 Aug 2005, Henning P. Schmiedehausen wrote:

> Thomas Fischer <fischer@seitenbau.net> writes:
>
>> Hi,
>
>> If one has an association between objects by foreign key, (e.g. book ->
>> author association in the tutorial), Torque generates methods to get the
>> associated objects (e.g. Book.getAuthor() and Author.getBooks()). If the
>> associated object has not yet been retrieved, these methods silently ask
>> the database for the objects, using a new connection from the database
>> pool.
>> This is not at all what one wants if one wants to use transactions in an
>> application, because one wants to do all reads in the same transaction. I
>> therefore plan to do the following
>> 1) add a method getXXX(boolean silentDbFetch), which only hits the database
>> silently if silentDbFetch is set to true. If set to false and the
>> associated object(s) have not been retrieved yet, null is returned, even
>> though there might be associated objects in the database.
>
> -0 The classes are already too overloaded IMHO.

Ok, good point. One gets carried away sometimes. I will remove it again 
before I commit it (Personally I do not use it anyway)

>
>> 2 ) add a method getXXX(connection) for the n->1 direction, whcih uses the
>> provided connection if a db hit is necessary (in the book example, this
>> would be book.getAuthor(connection) (author.getBooks() was already present)
>
> +0;  this is better, but still not really good. The question is: Does it
> hurt? The database hit is read-only, so a rollback would only be
> necessary if you have some trigger in the database which does writing
> changes on a read-access. In the worst case you will get stale data,
> but personally I would always recommend to run with
> torque.objectIsCaching = false anyway.

Well, if one really cares about transaction safety, getting stale data 
_IS_ a problem. A big one. Certainly not if one wants to generate dynamic 
content for a web site, but remember the bank account scenarios in the sql 
textbooks ?

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.

>
>> 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).
>
> That sounds like the best way to go.
>

Yes, I also think this one is crucial. But the same as for the overcrowded 
classes goes for the generator properties: If there are too many of them, 
we have to make sure that every combination of them works as expected. The 
runtimetest does not ensure this automatically, which is a problem. One 
day I should look into being able to run the runtimetest for different 
combinations of generator properties sequentially.

    Thomas

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


Mime
View raw message