db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject RE: AbstractBaseManager vs. JDO Persistence Manager
Date Mon, 01 Aug 2005 19:20:25 GMT
Hi John,

On Fri, 29 Jul 2005 jmenke@chubb.com 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.


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

View raw message