← Back to team overview

mugle-dev team mailing list archive

Re: Behaviour of remove

 

I believe the association and disassociation is set up correctyl (I checked about half the classes last night). Note you DO specifically have to call these add and remove methods on the client side in the UI for security reasons.




On 25/05/2011, at 11:35 AM, Matt Giuca <matt.giuca@xxxxxxxxx> wrote:

I think removals should always cascade down, but not up. (The "not up" means you still need to carefully delete down-references).

For example, deleting a Game should delete all of its GameVersions, but deleting a GameVersion should not delete the Game, so you need to remove the GameVersion reference from the Game.

Having said that, there need to be things that you simply cannot delete, because there is too much valuable data in them that you don't control. I don't think you should be able to delete a Game if it has any UGPs in it.

So let's look at all the objects and their deletion policy:
Achievement -- Cascading delete all UserAchievements
DevTeam -- Cascading delete all Games; observing the Game delete restriction
User -- Cascading delete all UserGameProfiles
Game -- Cascading delete all GameVersions, PromotedGames; cannot delete if there are any associated UserGameProfiles
GameVersion -- Cascading delete all GameFiles
GameFile -- Cascading delete all GameFileContents if they are not referenced by another GameFile GameFileContents -- Cannot delete if there are any associated GameFiles
PromotedGame -- OK
UserGameProfile -- Cascading delete all UserAchievements, KeyValuePairs
UserAchievement -- OK
KeyValuePair -- OK
Note that even though you can't really delete DevTeams (pretty much any devteam that has published a game), you can still remove users or take users out of devteams, so that provides the necessary indirection to have a user disassociate with a game but keep the game alive.

Also I think administrators should be able to override the Game delete restriction and actually delete a game and all associated UGPs.

Does the above sound reasonable? Now I don't think deletes are really that important. What is more important is disassociation. For example, if I have a user in a devteam and I want to remove the user from that devteam -- it isn't particularly important whether the devteam is deleted or not, I just want to disassociate the user from the devteam. Besides, if I can disasassociate a user from a devteam, an admin can safely delete the DevTeam object in the datastore.

Follow ups

References