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 16:19:45 GMT
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.

> 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).

> 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);

> 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.

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