Hi Bert, > Does the problem with object identities mean that OJB is not the right > way to go when building forms that display editable lists? If that is > that case I lost quite a lot of time just trying to find an quicker way > to build web forms. > What are the limitiations of OJB exactly?
thought I'd point this out to you, since it cost me a lot of time and I still haven't solved it in a satisfying way. AFAIK, there is a bug in the current OJB release rc5 with the use of javax.jdo.Query (as you use in your retrieve method). The objects in the collection it returns are actually not persistent as they should be. The nasty implication is: You retrieve a collection, you edit it via your form. You call transaction.commit() and the database doesn't get updated! The only way to retrieve a persistent object is by using getObjectByIdentity (or something like that) like they do in the JDO tutorial on the OJB site. They recently fixed the bug (get the latest CVS HEAD and compile it yourself), however, I am still running into a problem: I have got an object of class User that contains a field roles that is a collection of Role objects. When I retrieve a collection of User objects via Query, the respective Role objects are retrieved with them automatically. The users are persistent as they should be (thanks to the bug being fixed), the connected roles however still aren't. So by the time you commit, OJB tries to re-create the roles in the database and you get duplicate key errors. I haven't had the time yet to ask the OJB people about it. This is not to do with your current problems, but I thought I'd point it out to you before you run into it. For the moment, I actually gave up on OJB-JDO after spending a lot of time on it and just use the OJB PersistenceBroker-API which so far works perfectly and reliably for my relatively small persistence needs. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
