Hi Armin > -----Oorspronkelijk bericht----- > Van: Armin Waibel [mailto:[EMAIL PROTECTED] > > Hi Bart, > > Bart Molenkamp wrote: > > Hi, > > > > I'm using OJB 1.0.3, and I'm still having problems when storing large > > object graphs (which I already had). > > Could you describe more detailed the problems (sorry I can't remember > your last post)? >
See below. > > > I solved this problem, by listening > > to the PBStateListener.afterBegin() method. In this method, I use the > > metadata from the OJB metadata manager to clone myself a new object, > > which has no relationships to any other objects. This object is then > > stored using the persistence broker. This is done for all objects that > > are made persistent. After this, all objects are stored again, but now > > including all relationships etc. This works pretty good for me. > > > > What's the advantage of storing a "flat" object copy before storing the > real object? > I want to store a large graph of objects at once. To avoid getting referential integrity contraints violations (there are many references/collections in the tree, including parent/child relations), I first store a flat object, so it is known in the database (I do that for all objects that are new). Then I update all the objects with all their relationships. This way, I can't violate referential integrity. This does not work for all objects, e.g. those that have a foreign key in their primary key, but it works for my objects. > > But now I'm having a little problem, when locking a persistent object > > that has a reference to a new object. The ODMG layer marks this object > > as StateNewDirty. I also insert the new object in > > PBStateListener.afterBegin(). So I get an error, as OJB tries to insert > > the object twice. > > > > Is there anyway that I can set the state to StateOldClean or something, > > to let OJB know that it shouldn't care about that object anymore? > > Letting OJB do the insert fails (the graph problem). > > there is no "official" way to change object state in OJB's odmg > implementation. You need access to the ObjectEnvelopeTable instance used > by TransactionImpl (field is protected, so you have to use reflection). > In this case you can lookup the ObjectEnvelope instance for the > persistent object and change the state of the object. > I've solved it by extending TransactionImpl with my own imlpementation that stores flat objects before storing real objects. This seems to work good for me. But what about a get method for the envelope table on TransactionExt, or TransactionImpl? In that case, I don't have to extend TransactionImpl. Bart. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
