Hi John, On Fri, 29 Jul 2005 [EMAIL PROTECTED] wrote:
Thomas, I found this information regarding JDO PersistenceManager <SNIP> Your object model is usually composed of a set of classes with many interrelationships. The graph of all the related instances of those classes may include the entire contents of the datastore, but typically your applications deal with only a small number of the persistent instances at a time. JDO provides the illusion that your application can access the entire graph of connected instances, while in reality it only instantiates the small subset of instances that the application needs. This concept is called transparent data access, transparent persistence, or simply transparency. A PersistenceManager manages the persistent instances accessed from a datastore. It provides methods to make instances persistent and to delete instances from the datastore. It also provides factory methods to construct Extent and Query instances, which you use to access instances from the datastore. A PersistenceManager can manage any number of persistent instances at a time. Each instance of a persistent class is associated with one PersistenceManager or zero PersistenceManagers. A transient instance is not associated with any PersistenceManager instance. As soon as an instance is made persistent or transactional, it is associated with exactly one PersistenceManager. </SNIP> This sounds similar to your AbstractBaseManager in that it manages instances but it appears that PersistenceManager adds support for lifecycle methods: deletePersistentAll( ) evictAll( ) makeNontransactionalAll( ) makePersistentAll( ) makeTransactionalAll( ) makeTransientAll( ) refreshAll( ) retrieveAll( ) This methods look similar to what is in the abstract BasePeer class.
This looks like a combination from the Peer classes and the object classes to me. The Peer classes would query the database and delete objects from the database, and the Object classes would save themselves into the database. The Manager classes would only come in if you would want to cache the instances a Peer class has retrieved from the database. I would try and manage without the Manager classes in Torque first.
Spring interfaces with JDO via the PersistenceManager. I think the idea is that there is one central access point into JDO through the PersistenceManager. Maxim has created some code that implements PersistenceManager like functions for Torque. Hopefully this will let us mirror the JDO design for the torque ORM package. Spring tries to be consistent in implementation and I think Thomas Risberg would approve of that design.
Hm, if you would ask me for the most central place to interface with Torque I would use the generated Peer classes. I would not use BasePeer for it, because BasePeer cannot handle specific objects (for example, BasePeer does not know how to create a Book Object from a row of the BOOK table in the database, only BookPeer knows how to do that). What makes Torque different from most other Object-Relational managers is that Torque uses very little reflection, but rather relies on generated classes, so there is no "central" class. If one insists that there should be _ONE_ central class to access the database, this smells like trouble, I do not think Torque would fit very well into this approach. Probably one would do best to generate that central class as well. But this is just guesswork, there is a good probablility that I am wrong.
Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
