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 Tue, 16 Aug 2005 20:41:14 GMT

On Tue, 16 Aug 2005, Thomas Vandahl wrote:

> Thomas Fischer wrote:
>> Some time after that I want to access the data I have stored, e.g. because 
>> the user has submitted a command in an HTML form to change the data. The 
>> only "official" (i.e. automatically generated) way to get the cached Books 
>> from an author is to use author.getBooks(). But I care about the data being 
>> consistent, so in no circumstances do I want to access the database, 
>> because this would break transaction safety and lead to inconsistent data 
>> if soneone elase has changed the data in the menatime. Especially, if, by 
>> some mistake, I did forget to read the books of an author, I want to know 
>> it. A logical way of knowing is that author.getBooks() returns null.
> If you are /sure/ that you're using the very same instance of your author to 
> modify something, there is every reason to believe that your books fetched 
> before are still there. I see your point for debugging purposes. But that 
> should not happen in production code.

Yes. But to be sure that it does not happen, one needs to get a clean 
error each time one tries to make it happen. If one does not get a clean 
error, but a silent db hit instead, the chance that someone notices during 
development that something is wrong is very small. I have seen it.

>> I am personally using xslt, but that does not play any role. The problem is 
>> that I have no idea to provide the methods when managers are turned on. The 
>> implementation without the connection asks the manager to provide the 
>> object, and there is no way I have found to tell the manager "get that 
>> object, but if it is not there, use the provided connection". So I did not 
>> implement it in objectWithManager.vm. Do you have any idea of how to solve 
>> this one ?
> Not without bigger changes in the AbstractBaseManager. I will have a look at 
> this. I guess the real fun starts if I want to cache the whole collection of 
> books at once (using MethodResultCache for example, not to speak of 
> invalidation).

I must admit that I have only the slightest idea what the Managers do (I 
was never tempted to use them, given that I cannot imagine they work very 
well if you have different JVMs writing to the same database), so if you 
think this could be useful and would take a look at it, I would be very 

>> If you transfer it to java, yes. I would explicitly use book.getAuthor()
>> in the presentation layer.
> I see your point. With Velocity it makes no difference:
> 	Author a = AuthorPeer.retrieveByPK(id, con);
> 	context.put("author", a);
> 	List books = a .getBooks(con);
> 	context.put("books", books);

It would make a difference if yoor object tree gets more complex. Just 
imagine you would have a list of authors, each of 
which has a list of books. So using caching, it would be just two lines

List authors = AuthorPeer.doSelectJoinBooks(criteria, connection);
context.put("authors", authors);

Without caching, that would be horrible (i.e. you would have to 
reconstruct the structure cahcing already provides.) This will get 
worse if your object tree gets more and more complicated.

>> I would not think so. If one knows that the property torque.objectIsCaching 
>> exists, in the generator, and one decides not to set it to false, one 
>> explicitly wants to have the caching. And if one has it, is it not legimite 
>> to say "I only want to use the cached data, and not hit the database"
> Still it looks a bit clumsy to me.

Yes, it certainly is, but I did not see a better way to give the user that 
choice. Another way would have been to add another method getXXX(boolean 
silentDbHit), but I already had Henning's flames on that, and he is right 
(we already have too many methods in the object classes).

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

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

View raw message