0003059: Non-root prims deleted shortly after delink always reappear on server restart

(0009053)
idb (manager)
2009-01-29 04:43

Perhaps if, when an object is being deleted, if the changed flag is true (and preferably only if the change includes delinking), then the object could be persisted before the delete to ensure the keys are up to date before the delete.

Or if both old and new ids are available, the database delete could be tried for both keys

(0009054)
idb (manager)
2009-01-29 05:46

I was just wondering if any other operations carried out on newly unlinked prims might have problems because of the ID change. Possibly rapid linking and unlinking in different order or different combinations of prims

(0009055)
justincc (manager)
2009-01-29 07:28
edited on: 2009-01-29 07:28

I like your persist before delete idea idb - I think that might just work. It seems a bit bizarre to have to update a row in order to then go and delete it. But I think that it does have the merit of being conceptually simple - combining the two operations would mean a new database interface method I suspect. I suspect doing two operations is also simpler when we come eventually to support multi-depth linksets.

Trying a delete for both keys will not work since before the unlink occurs, all prims will have the same SceneGroupID. So trying a delete using the old id will end up deleting all the prims in the old linkset. Also, it seems horribly hacky :)

I suspect we won't see this problem on link/delink, since these operations all update rows in the database rather than do any deletions. All the updating link/delink operations should occur in the order in which the user performed them (unless you can think of some corner case).

(0009056)
justincc (manager)
2009-01-29 11:25

Just for anybody else who reads this, the workaround for this bug is to wait a couple of minutes before deleting something that you've unlinked. Though I imagine this could be somewhat annoying for content developers.

(0009057)
idb (manager)
2009-01-29 11:59
edited on: 2009-01-29 12:00

This may also affect setting an object to temporary after unlink but before it is persisted with new keys, I think that also removes the object from the db so may also fail like delete

(0009155)
justincc (manager)
2009-02-04 08:14

Hopefully resolved in r8238

(0015594)
Snoopy (reporter)
2010-06-07 09:22

This problem is back in 0.6.9 post-fixes, tested with git version e4114799c3b25cd54d409a686175f39d1ec5b25b.

(0015595)
melanie (administrator)
2010-06-07 09:24

please test master/0.7Dev

Issue History
Date Modified	Username	Field	Change
2009-01-28 11:04	justincc	New Issue
2009-01-28 11:04	justincc	SVN Revision	=> 8170
2009-01-28 11:04	justincc	Run Mode	=> Standalone (1 Region)
2009-01-28 11:04	justincc	Physics Engine	=> ODE
2009-01-28 11:04	justincc	Environment	=> Mono / Linux32
2009-01-28 11:04	justincc	Mono Version	=> 1.9.1
2009-01-29 04:43	idb	Note Added: 0009053
2009-01-29 05:46	idb	Note Added: 0009054
2009-01-29 07:28	justincc	Note Added: 0009055
2009-01-29 07:28	justincc	Note Edited: 0009055
2009-01-29 11:25	justincc	Note Added: 0009056
2009-01-29 11:59	idb	Note Added: 0009057
2009-01-29 12:00	idb	Note Edited: 0009057
2009-02-04 08:08	justincc	Relationship added	has duplicate 0001004
2009-02-04 08:14	justincc	Status	new => resolved
2009-02-04 08:14	justincc	Resolution	open => fixed
2009-02-04 08:14	justincc	Assigned To	=> justincc
2009-02-04 08:14	justincc	Note Added: 0009155
2009-02-04 08:20	justincc	Relationship added	child of 0002870
2009-02-12 18:12	chi11ken	Status	resolved => closed
2010-06-07 08:52	fineman	Relationship added	related to 0004756
2010-06-07 09:22	Snoopy	Status	closed => feedback
2010-06-07 09:22	Snoopy	Resolution	fixed => reopened
2010-06-07 09:22	Snoopy	Note Added: 0015594
2010-06-07 09:24	melanie	Note Added: 0015595

Notes
(0009053) idb (manager) 2009-01-29 04:43	Perhaps if, when an object is being deleted, if the changed flag is true (and preferably only if the change includes delinking), then the object could be persisted before the delete to ensure the keys are up to date before the delete. Or if both old and new ids are available, the database delete could be tried for both keys

(0009054) idb (manager) 2009-01-29 05:46	I was just wondering if any other operations carried out on newly unlinked prims might have problems because of the ID change. Possibly rapid linking and unlinking in different order or different combinations of prims

(0009055) justincc (manager) 2009-01-29 07:28 edited on: 2009-01-29 07:28	I like your persist before delete idea idb - I think that might just work. It seems a bit bizarre to have to update a row in order to then go and delete it. But I think that it does have the merit of being conceptually simple - combining the two operations would mean a new database interface method I suspect. I suspect doing two operations is also simpler when we come eventually to support multi-depth linksets. Trying a delete for both keys will not work since before the unlink occurs, all prims will have the same SceneGroupID. So trying a delete using the old id will end up deleting all the prims in the old linkset. Also, it seems horribly hacky :) I suspect we won't see this problem on link/delink, since these operations all update rows in the database rather than do any deletions. All the updating link/delink operations should occur in the order in which the user performed them (unless you can think of some corner case).

(0009056) justincc (manager) 2009-01-29 11:25	Just for anybody else who reads this, the workaround for this bug is to wait a couple of minutes before deleting something that you've unlinked. Though I imagine this could be somewhat annoying for content developers.

(0009057) idb (manager) 2009-01-29 11:59 edited on: 2009-01-29 12:00	This may also affect setting an object to temporary after unlink but before it is persisted with new keys, I think that also removes the object from the db so may also fail like delete

(0009155) justincc (manager) 2009-02-04 08:14	Hopefully resolved in r8238

(0015594) Snoopy (reporter) 2010-06-07 09:22	This problem is back in 0.6.9 post-fixes, tested with git version e4114799c3b25cd54d409a686175f39d1ec5b25b.

(0015595) melanie (administrator) 2010-06-07 09:24	please test master/0.7Dev