I figure that we want to get the state manager set as early as possible because it may be needed by any class that handles the PC objects generated in the extent. So the first place I could find that one gets a handle on the results of an extent call was the constructor for OJBExtent. (please tell me if there is an earlier/better point to get to the results)
I tried hacking the Constructor to look like this just to see if it fixed the problem:
private Iterator iterator; private Class clazz; private PersistenceBroker broker;
/**
* Constructor for OjbExtent.
*/
public OjbExtent(Class pClazz, PersistenceBroker pBroker)
{
clazz = pClazz;
System.out.println(pBroker.getClass());
Criteria selectExtent = null;
Query q = QueryFactory.newQuery(clazz, selectExtent);
broker = pBroker;
RsIterator iter = (RsIterator) broker.getIteratorByQuery(q);
// cycle through the extent and give the objects a statemanager
ArrayList temp = new ArrayList();
while (iter.hasNext()) {
Object o = iter.next();
Identity oid = new Identity(o, broker);
PersistenceCapable pc;
// theoretically this should never happen, but...
if (o instanceof PersistenceCapable) {
pc = (PersistenceCapable) o;
} else {
throw new RuntimeException("OJBExents are returning classes " +
"that are not javax.jdo.spi.PersistenceCapapble??");
}
// FIXME:
// Something of a Hack... The current implementation of JDO in OJB
// guarantees that this cast works, but I don't think it is
// in any way guaranteed not to change.
PersistenceManagerImpl pm = (PersistenceManagerImpl) pc.jdoGetPersistenceManager();
StateManagerInternal sm = pm.findStateManager(pc);
pc.jdoReplaceStateManager(sm);
temp.add(pc);
}
iter.releaseDbResources();
this.iterator = temp.iterator();
}
I never got to see if this had an effect though because it caused a very surprising NPE... pc.jdoGetPersistenceManager() is returning null. So not only do the objects not have a state manager, they don't have a persistence manager! Any clue how to address this?? I don't see any way to generate and supply a PersistenceManager for the object.
I have a feeling that there is some other place I should be looking.... I feel like I don't yet understand how the sun RI gets diverted/configured into using the OJB backend.... That seems like another possible point of attack but I havn't found it yet.
-Gus
Mahler Thomas wrote:
Hi Gus,
Yes, I hope to get my hands on the open JDO issues very soon!
Thomas
-----Original Message----- From: Gus Heck [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 7:59 PM To: OJB Users List Subject: Re: JDO Bug (status please)
I just got bit by this, despite the fact I had read this thread. I forgot and coded a method that asked if an object is persistant, and if not caused it to get a new ID and make itself persistant.
I noticed something interesting though.... I edited and changed an object, then inadvertently created a copy of it because of the ID aquisition issue I just described, but when I did another extent to display a list of all items, both the old object and the inadvertently created object were identical right down to the ID. Logging intto mysql and doing a select shows that this is not what has happened in the DB. So it looks like the transient objects returned by the extent are still cached objects and may become modified without effecting the database.
This means that data can appear to be written to the database but in fact is not!
I hope you will have time to work on this very soon, I'm digging through the discussion referenced below and having trouble picking out what exactly the work around is... If you or someone else could post a direct workaround for getting a list of all objects of a class that are persistant it would help a lot.
TIA, Gus
Mahler Thomas wrote:
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
