Dain, Are you actively working on this? I'd be happy to fix it (in the manner you suggest, not my crack-induced version of it) if you don't have the time.
All I need is a pointer as to where the execution sequence comes from. (I suppose I could figure it out, but if you know where it is, it'll save time) Not trying to push or anything, I just need to know if your working on it so I can get rid of my cascade-delete tags until the fix gets comitted, or if I should take a shot at fixing it since I have a re-producable test case for it. Thanks, -David On Tuesday 06 November 2001 01:54pm, you wrote: > Bugs item #478783, was opened at 2001-11-06 09:35 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=478783&group_id >=22866 > > Category: JBossCMP > Group: v2.5 Rabbit Hole (unstable) > Status: Open > Resolution: None > Priority: 5 > Submitted By: David Budworth (dbudworth) > Assigned to: Dain Sundstrom (dsundstrom) > Summary: CMR records are deleted out of order > > Initial Comment: > In a 1:1 CMR, the master bean is deleted before the > child bean. > > If you have: > Order -> ShippingAddress > With cascade delete turned on > > And you perform Order.remove() > > SQL Executed is: > > DELETE FROM order WHERE id = ? > UPDATE order SET shippingaddress_id = ? WHERE id = ? > > Which is really hard to do in a database > > I believe that it should be: > DELETE FROM shippingaddress WHERE id = ? > UPDATE order SET shippingaddress = ? WHERE id = ? > DELETE FROM order WHERE id = ? > > (Yes, I know it doesn't make sense to update order > right before you delete it, but it seems to be a > byproduct of the interceptor stack system) > > Note: The above is a simplified version of my > relations. My actual relation (in case it matters) > is: > Customer --1:n--> Order --1:1--> ShippingAddress > And this happens when I call Customer.remove() > > > > ---------------------------------------------------------------------- > > >Comment By: Dain Sundstrom (dsundstrom) > > Date: 2001-11-06 13:54 > > Message: > Logged In: YES > user_id=251431 > > You are on crack. :) > > The spec says "After the bean provider’s ejbRemove() > method returns (and prior to returning to the client), the > Container must remove the entity object from all > relationships in which it participates, and then remove its > persistent representation... After removing the entity > object from all relationships and removing its persistent > representation, the Container must then cascade the > removal to all entity beans with which the entity had been > previously been in container-managed relationships > for which the cascade-delete option was specified." So this > is what happens when you run order.remove(): > > 1. "the bean provider’s ejbRemove()method returns" > > 2. "remove the entity object from all relationships in > which it participates" > UPDATE order SET shippingaddress_id = ? WHERE id = ? > > 3. "then remove its persistent representation" > DELETE from order where id = ? > > 4. "cascade the removal to all entity beans with which the > entity had been previously been in container-managed > relationships for which the cascade-delete option was > specified" > DELETE FROM shippingaddress where ID = ? > > Follow? > > This means that not null foreign keys do not currently > work. The spec did give us a way out of this in footnote > 11 ("At this point it must appear to the application that > the entity has been removed from the persistent store. If > the container employs an optimistic caching strategy and > defers the removal of the entity from the database (e.g., > to the end of transaction), this must be invisible to the > application."), but this feature has not been implemented > yet. > > -dain > > ---------------------------------------------------------------------- > > Comment By: David Budworth (dbudworth) > Date: 2001-11-06 13:01 > > Message: > Logged In: YES > user_id=343354 > > Which spec version are you reading? > ejb-2_0-fr-spec.pdf says: > "As with the remove operation. the removal triggered by > the cascade-delete option causes the container to invoke > the ejbRemove() method on the entity bean instance that is > to be removed before the persistent representation of that > entity object is removed" > > That to me sounds like : > shippingaddress.remove(){ > DELETE FROM shippingaddress where ID = ? > } > order.store(){ > UPDATE order SET shippingaddress_id = ? WHERE id = ? > } > order.remove(){ > DELETE from order where id = ? > } > > Maybe I have the wrong spec? Or am I just on crack and > not reading it correctly (entirely possible) > > > > ---------------------------------------------------------------------- > > Comment By: Dain Sundstrom (dsundstrom) > Date: 2001-11-06 10:12 > > Message: > Logged In: YES > user_id=251431 > > The ejb 2.0 final draft spec requires that the persistence > representation is removed then the related entieites are > cascad-deleted (section 10.3.4.2). This means that the > following sql should be executed: > > UPDATE order SET shippingaddress_id = ? WHERE id = ? > DELETE FROM order WHERE id = ? > DELETE FROM shippingaddress WHERE id = ? > > The both of the sequences you present are wrong, so I'll > check if the sequence I presented is occuring. Unless you > can show me where in the spec your version is allowed, it > won't be implemented. > > -dain > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=478783&group_id >=22866 > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
