db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <Thomas....@seitenbau.net>
Subject Re: template changes to add filler methods
Date Tue, 21 Jun 2011 20:45:37 GMT

>> Any objections or comments to the above ? If not, I'll commit the
>> in a few days.

>If I understand the concept correctly, this is one more method to deal
>with related entities. Each of them may have its advantages and
>disadvantages, however I'm afraid it gets a bit crowded in the Peer
>classes. WDYT?

It is my favourite method because it is the fastest no-think method of
loading the related objects I know. I have solved lots of performance
problems at work using this method (even with other ORM frameworks).

But as I said, the methods can be turned off via a generation option, and
the default is that the methods are generated. If you are more happy with
the default that the methods are not generated, I can easily change it.

> One more (related) thing: Other ORM tools provide the feature that an
> object with the same primary key is actually always the same object
> instance, IOW:
> Book b1 = BookPeer.retrieveByPK(1);
> Book b2 = BookPeer.retrieveByPK(1);
> will yield b1 == b2 while Torque only achieves b1.equals(b2) Do we have
> some way to handle this? Or is this completely off?

Which scope should the bX object have ? JVM Scope (then use Managers, as
Chris suggested). Personally I do not like JVM scope because it makes a
mess of concurrent changes on the same object in the same JVM (e.g.
concurrent edits in web applications). To get a smaller scope, other ORM
tools have the concept of a "session" and the objects (can) have session
scope. I do not currently have the energy to add a session concept to
Torque (and I have not thought in which cases a session concept is better
or worse than the current concept)


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

View raw message