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
glad.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
