更新时间:2025-08-08 GMT+08:00
分享

软删除使用示例

数据准备

此处需要提前准备示例使用的数据库表,并初始化一些软删除功能示例使用的测试数据,具体的建表语句如下:

CREATE TABLE `t_order` (
    `id` varchar(40) NOT NULL COMMENT 'id',
    `name` varchar(200) NOT NULL,
    `soft_delete_flag` bigint(0) NOT NULL DEFAULT '0' COMMENT '软删除标记字段,为时间戳表示此数据执行了软删除操作,时间戳记录了软删除的时间,为0表示没有执行软删除操作;searchable',
    PRIMARY KEY (`id`)
) COMMENT = 'primaryKeyType("UUID")';

INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('1', 'test1', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('2', 'test2', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('3', 'test3', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('4', 'test4', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('5', 'test5', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('6', 'test6', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('7', 'test7', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('8', 'test8', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('9', 'test9', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('10', 'test10', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('11', 'test11', 0);
INSERT INTO `softdelete`.`t_order`(`id`, `name`, `soft_delete_flag`) VALUES ('12', 'test12', 0);

构建服务

  1. 登录AstroPro控制台,单击“进入首页”,进入AstroPro实例。
  2. 在左侧导航栏中,选择后端开发平台 > 服务管理 > 服务
  3. 选择项目和服务组,单击“新建服务”,新建一个SoftDelete的服务。
  4. 在服务列表中,单击SoftDelete服务后的“编辑”
  5. 编辑服务(基本配置、框架配置和生成策略都选择默认值)。

    1. 拖拽一个BO对象到设计区,并修改对象名称为Order。
    2. 在Order对象中新增一个name字段,String类型,长度200。
    3. 在业务界面选中Order对象,在右边属性配置中开启软删除策略和恢复软删除策略。
    4. “操作”下拉框中,勾上全选。

  6. 设置完成后,单击“下一步”
  7. 输入变更日志描述信息,单击“创建”

    系统开始创建服务,并生成该服务的基本代码。

删除

  • API层代码
    通过构建服务生成的代码中删除的API层代码如下:
    @ApiOperation(value = "通过Order的id删除Order", nickname = "deleteOrderById", notes = "Delete a single Order", response = Integer.class, tags = { "Order" })
    @ApiResponses(value = { @ApiResponse(code = 200, message = "successful operation", response = Integer.class), @ApiResponse(code = 404, message = "Order not found") })
    @RequestMapping(value = "/v1/orders/{order_id}", produces = { "application/json" }, method = RequestMethod.DELETE)
    ResponseEntity<Message<Integer>> deleteOrderById(@Parameter(in = ParameterIn.PATH, description = "order_id", required = true, schema = @Schema()) @PathVariable("order_id") String orderId, @ApiParam(value = "Specifies the deletion type of the control interface(default value: false). true:hard deletion false:soft deletion") @RequestParam(value = "hard_deletion", required = false) Boolean hardDeletion);
  • 业务层代码
    通过构建服务生成的代码中删除的业务层代码如下:
    /**
     * DeleteOrderById Method
     *
     * @param orderId orderId
     * @param hardDeletion hardDeletion
     * @return Integer
     */
    @Override
    public Integer deleteOrderById(String orderId, Boolean hardDeletion) {
    	return orderRepositoryService.softDeleteOrderById(orderId, hardDeletion);
    }
  • Postman调用
    • 通过Postman调用单条删除的API,对id为1的数据执行软删除操作。

      API参数中order_id设置为1,hard_deletion设置为false,调用过程和API返回值如图1所示。

      预期结果:API返回值中status为200,message为success,data为1。查询数据库后id为1的数据的soft_delete_flag字段被更新为一个非0的时间戳。
      图1 软删除id为1数据

      执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图2所示。

      图2 查询软删除后结果

      结论:id为1的数据的soft_delete_flag字段被更新为一个非0的时间戳,即单条删除API的软删除操作成功。

    • 通过Postman调用单条删除的API,对id为2的数据执行物理删除操作。

      API参数中order_id设置为2,hard_deletion设置为true,调用过程和API返回值如图3所示。

      预期结果:API返回值中status为200,message为success,data为1。查询数据库后,在查询结果中没有id为2的数据。

      图3 物理删除id为2的数据

      执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图4所示。

      图4 查看物理删除后的结果

      结论:数据库中没有id等于2的数据,即单条删除的API物理删除操作成功。

批量删除

  • API层代码
    通过构建服务生成的代码中批量删除的API层代码如下:
    @ApiOperation(value = "通过Order的id批量删除Order", nickname = "deleteOrderByIds", notes = "Delete the Order whose id is contained in ids.", response = Integer.class, tags = { "Order" })
    @ApiResponses(value = { @ApiResponse(code = 200, message = "successful operation", response = Integer.class), @ApiResponse(code = 404, message = "Order not found") })
    @RequestMapping(value = "/v1/orders/batch-delete", produces = { "application/json" }, consumes = { "application/json" }, method = RequestMethod.POST)
    ResponseEntity<Message<Integer>> deleteOrderByIds(@NotNull @ApiParam(value = "deleteOrderByIdsRequestBody", required = true) @Valid @RequestBody List<String> body, @ApiParam(value = "Specifies the deletion type of the control interface(default value: false). true:hard deletion false:soft deletion") @RequestParam(value = "hard_deletion", required = false) Boolean hardDeletion);
  • 业务层代码
    通过构建服务生成的代码中批量删除的业务层代码如下:
    /**
     * DeleteOrderByIds Method
     *
     * @param orderIds orderIds
     * @param hardDeletion hardDeletion
     * @return Integer
     */
    @Override
    public Integer deleteOrderByIds(List<String> orderIds, Boolean hardDeletion) {
    	return orderRepositoryService.softDeleteOrderByIds(orderIds, hardDeletion);
    }
  • Postman调用
    • 通过Postman调用批量删除的API,对id为3和id为4的数据执行软删除操作。

      API参数中body体中传入3和4 ,hard_deletion设置为false,调用过程和API返回值如图5所示。

      预期结果:API返回值中status为200,message为success,data为2。查询数据库后id为3和id为4的数据的soft_delete_flag字段被更新为一个非0的时间戳。

      图5 批量软删除

      执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图6所示。

      图6 查看批量软删除结果

      结论:id为3和id为4的数据的soft_delete_flag字段被更新为一个非0的时间戳,批量软删除操作成功。

    • 通过Postman调用批量删除的API,对id为5和id为6的数据执行物理删除操作。

      API参数中body体中传入5和6 ,hard_deletion设置为true,调用过程和API返回值如图7所示。

      预期结果:接口返回值中status为200,message为success,data为2。查询数据库后没有id为5和id为6的数据。

      图7 批量物理删除

      执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图8所示。

      图8 查看批量物理删除结果

      结论:数据库中没有id为5和id为6的数据,即批量物理删除操作成功。

查询

  • API层代码
    通过构建服务生成的代码中查询的API层代码如下:
    @ApiOperation(value = "通过Order的id查询Order", nickname = "showOrderById", notes = "Returns a single Order", response = Order.class, tags = { "Order" })
    @ApiResponses(value = { @ApiResponse(code = 200, message = "successful operation", response = Order.class), @ApiResponse(code = 404, message = "Order not found") })
    @RequestMapping(value = "/v1/orders/{order_id}", produces = { "application/json" }, method = RequestMethod.GET)
    ResponseEntity<Message<Order>> showOrderById(@Parameter(in = ParameterIn.PATH, description = "order_id", required = true, schema = @Schema()) @PathVariable("order_id") String orderId, @ApiParam(value = "") @RequestParam(value = "soft_deleted", required = false) Boolean softDeleted);
  • 业务层代码
    通过构建服务生成的代码中查询的业务层代码如下:
    /**
     * GetOrderById Method
     *
     * @param orderId orderId
     * @param softDeleted softDeleted
     * @return Order
     */
    @Override
    public Order getOrderById(String orderId, Boolean softDeleted) {
    	return orderRepositoryService.findOrderByIdWithSoftDeleted(orderId, softDeleted);
    }
  • Postman调用
    • 通过Postman调用单条查询的API,对id为1的数据执行查询操作,此时只查询没有被软删除的数据。

      API参数中order_id传入1 ,soft_deleted设置为false(此处设置为false的含义是查询没有被软删除的数据),调用过程和API返回值如图9所示。

      预期结果:因为id为1的数据在之前的操作中已被软删除,所以接口返回值中status为200,message为success,data为null。

      图9 id为1数据soft_deleted传入false

      执行完上述操作后,在数据库执行select * from t_order命令, 数据库执行结果如图10所示。

      图10 查看数据

      结论:当前数据库中id为1的数据的soft_delete_flag字段为非0的时间戳,而调用的单条查询API的返回值中data为null,没有查询到id为1的数据,所以单条查询非软数据数据操作成功。

    • 通过Postman调用单条查询的API,对id为1的数据执行查询操作,此时查询不关心数据是否被软删除,只要数据在数据库中存在就需要查询出来。

      API参数中order_id传入1 ,soft_deleted设置为true(此处设置为true的含义是查询操作不关心数据是否被软删除,只要存在就查询出来),调用过程和API返回值如图11所示。

      预期结果:虽然id为1的数据在之前的操作中被软删除了,但本次查询不考虑软删除状态,所以API返回值中status为200, message为success,data为数据中id为1的数据的json格式。

      图11 id为1数据soft_deleted传入true

      执行完上述操作后,在数据库执行 select * from t_order命令,数据库执行结果如图12所示。

      图12 查看id为1数据

      结论:虽然数据库中id为1的数据的soft_delete_flag字段为非0的时间戳,但API的返回值status为200,message为success,data为数据库中id为1的数据的json格式,所以单条查询忽略软删除值数据的操作成功。

    • 通过Postman调用单条查询的API,对id为7的数据执行查询操作,此时查询不关心数据是否被软删除,只要数据在数据库中存在就需要查询出来

      API参数中order_id传入7 , soft_deleted设置为true(此处设置为true的含义是查询操作不关心数据是否被软删除,只要存在就查询出来),调用过程和API返回值如图13所示。

      预期结果:id为7的数据在之前未被软删除,但本次查询不考虑软删除状态,因此API返回值中status为200, message为success,data为数据中id为7的数据的json格式。

      图13 id为7数据soft_deleted传入true

      执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图14所示。

      图14 查看ID为7数据

      结论:数据库中id为7的数据的soft_delete_flag字段为0,数据未被软删除。因此API的返回值status为200,message为success,data为数据库中id为7的数据的json格式,即单条查询忽略软删除值数据的操作成功。

恢复软删除

  • API层代码
    通过构建服务生成的代码中恢复软删除的API层代码如下:
    @ApiOperation(value = "通过order的id恢复已被软删除order", nickname = "recoverySoftDelOrderById", notes = "Recovery a single order", response = Integer.class, tags = { "Order" })
    @ApiResponses(value = { @ApiResponse(code = 200, message = "successful operation", response = Integer.class), @ApiResponse(code = 404, message = "order not found") })
    @RequestMapping(value = "/v1/orders/{order_id}/recovery", produces = { "application/json" }, method = RequestMethod.POST)
    ResponseEntity<Message<Integer>> recoverySoftDelOrderById(@Parameter(in = ParameterIn.PATH, description = "order_id", required = true, schema = @Schema()) @PathVariable("order_id") String orderId);
  • 业务层代码
    通过构建服务生成的代码中恢复软删除的业务层代码如下:
    /**
     * RecoverySoftDelOrderById Method
     *
     * @param orderId orderId
     * @return Integer
     */
    @Override
    public Integer recoverySoftDelOrderById(String orderId) {
    	return orderRepositoryService.recoverySoftDelOrderById(orderId);
    }
  • 通过Postman调用恢复软删除的API将id为1的数据变为非软删除状态。

    API参数中order_id设置为1,调用过程和API返回值如图15所示。

    预期结果:此时API返回值中status为200,message为success,data为1。因为id为1的数据在之前的操作中被软删除了,soft_delete_flag字段为非0的时间戳。执行完软删除恢复操作后再查询数据库,id为1的数据的soft_delete_flag字段应该为0。
    图15 恢复软删除

    执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图16所示。

    图16 查看恢复软删除数据

    结论:数据库中id为1的数据的soft_delete_flag字段为0,即恢复软删除操作成功。

批量恢复软删除

  • API层代码
    通过构建服务生成的代码中批量恢复软删除的API层代码如下:
    @ApiOperation(value = "通过Order的id批量恢复已被软删除Order", nickname = "recoverySoftDelOrderByIds", notes = "Recovery some Order through their ids", response = Integer.class, tags = { "Order" })
    @ApiResponses(value = { @ApiResponse(code = 200, message = "successful operation", response = Integer.class), @ApiResponse(code = 404, message = "Order not found") })
    @RequestMapping(value = "/v1/orders/batch-recovery", produces = { "application/json" }, consumes = { "application/json" }, method = RequestMethod.POST)
    ResponseEntity<Message<Integer>> recoverySoftDelOrderByIds(@NotNull @ApiParam(value = "recoverySoftDelOrderByIdsRequestBody", required = true) @Valid @RequestBody List<String> body);
  • 业务层代码
    通过构建服务生成的代码中批量恢复软删除的业务层代码如下:
    /**
     * RecoverySoftDelOrderByIds Method
     *
     * @param orderIds orderIds
     * @return Integer
     */
    @Override
    public Integer recoverySoftDelOrderByIds(List<String> orderIds) {
    	return orderRepositoryService.recoverySoftDelOrderByIds(orderIds);
    }
  • Postman调用

    通过Postman调用批量恢复软删除的API 将id为3和id为4的数据变为非软删除状态。

    API参数中 body体中传入3和4 , 调用过程和API返回值如图17所示。

    预期结果:API返回值中status为200, message为success,data为2。 因为id为3和id为4的数据在之前的操作中被软删除了,soft_delete_flag字段为非0的时间戳。执行完批量恢复软删除操作后查询数据库,id为3和id为4的数据的soft_delete_flag字段应该为0。

    图17 批量恢复软删除

    执行完上述操作后,在数据库执行select * from t_order命令,数据库执行结果如图18所示。

    图18 查看批量恢复软删除数据

    结论:数据库中id为3和id为4的数据的soft_delete_flag字段为0,批量恢复软删除操作成功。

相关文档