|
Martin Zaun made changes - 24/Mar/06 05:34 AM
Martin Zaun made changes - 24/Mar/06 05:53 AM
My preference is to put these methods into the runtime implementation of PersistenceManagerImpl. I don't feel strongly but I'm expecting that we will add the FetchPlan implementation into runtime20 and put at least a skeleton of the makeTransient methods into runtime20 as well. The structure of runtime20, core20, and fostore20 will need to be laid out in more detail when we get to the detail design phase.
Followed Craig's suggestion and added the missing makeTransient(*,boolean)
methods to PersistenceManagerImpl, so that derived FOStorePM compiles now. Sending runtime20/src/java/org/apache/jdo/impl/pm/PersistenceManagerImpl.java Transmitting file data . Committed revision 388538.
Martin Zaun made changes - 24/Mar/06 10:37 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
My thoughts:
- The implementation of the new methods
public void makeTransient(Object pc, boolean useFetchPlan)
public void makeTransientAll(Object[] pcs, boolean useFetchPlan)
public void makeTransientAll(Collection pcs, boolean useFetchPlan)
needs to go into either of
org.apache.jdo.impl.pm.PersistenceManagerImpl
org.apache.jdo.impl.fostore.FOStorePM.
Since PersistenceManagerImpl cannot implement this method generically, I felt that the implementation
should be in the backend-specific classes, i.e., FOStorePM.
- Because FOStorePM doesn't support the concept of a fetch plan, the methods could either throw an
UnsupportedOperationException or ignore the 'useFetchPlan' argument. Not throwing an exception
seems best to be, since the API/spec doesn't indicate those methods as being optional and the
semantics of ignoring the 'useFetchPlan' argument seems consistent to me if there's no fetch plan.