>> Any objections or comments to the above ? If not, I'll commit the changes >> 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) Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
