关于Liferay的deactivate user的研究

当用户在控制面板中选择deactivate user的时候：




它会去走到EditUserAction的processAction()方法，在判断清楚动作是Constants.DEACTIVATE之后，它会调用deleteUser()方法：




这段代码如下：

protected void deleteUsers(ActionRequest actionRequest) throws Exception {
String cmd = ParamUtil.getString(actionRequest, Constants.CMD);
long[] deleteUserIds = StringUtil.split(
ParamUtil.getString(actionRequest, "deleteUserIds"), 0L);
for (int i = 0; i < deleteUserIds.length; i++) {
if (cmd.equals(Constants.DEACTIVATE) ||
cmd.equals(Constants.RESTORE)) {
int status = WorkflowConstants.STATUS_APPROVED;
if (cmd.equals(Constants.DEACTIVATE)) {
status = WorkflowConstants.STATUS_INACTIVE;
}
UserServiceUtil.updateStatus(deleteUserIds[i], status);
}
else {
UserServiceUtil.deleteUser(deleteUserIds[i]);
}
}
}

可以发现deleteUser不仅仅是只删除用户，它是几种情况的糅合体，不仅仅是Delete,而且Deactivate,Restore都会走到这个方法中，我们因为是DEACTIVATE,所以走的分支是第16行，最终它先获取我们操作的用户的id,然后会调用UserServiceUtil.updateStatus(deleteUserIds[i]，status)方法：




这个方法接下来会利用动态代理机制调用UserServiceImpl的updateStatus(long userId,int status)方法：




这个方法从调试信息中可以看到，我们要操作的用户id是12113，然后状态位要改成5，这个5应该是对应的Deactivate。

最终，这个方法会调用UserLocalServiceImpl.updateStatus(userId,status)方法：


它其实是对用户表User_进行了操作，并且吧其中UserId 为12113（Jessica这个用户）的状态为改成了5(deactivate):

这个表的DDL如下：




特别注意第2个字段(UserId)和最后一个字段(Status).

而当我们进行操作的时候，很容易从Hypersonic数据库的log中看到我们更新这个字段的操作（不过不明白为什么Update要拆分2条，一条是Delete,一条是insert)




总结：
(1)其实当Deactivate用户时候，并没有真正让用户信息从User_表中删除，仅仅是吧Status位置改成Deactivate.
(2)用户的Restore,Deactivate,Delete操作都合并在了deleteUser()方法中。
(3)Hypersonic操作很不智能，Update方法必须被拆分为一个Delete加一个Insert方法