On Tue, 2 Aug 2005, Henning P. Schmiedehausen wrote:
Thomas Fischer <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
