Skip to main content

One-to-One Save

xuejmnet9/14/25About 6 min

One-to-One Save

One-to-one is a relatively special association relationship because one-to-one associations often have two situations:

  • Table A's id and Table B's id are associated in a one-to-one correspondence
  • Table A's id and Table B's non-id column are associated and then logically correspond one-to-one in the business (Table A comes first)

So are there differences in saving between these two situations? Actually, there are.

In the first situation, both are ids and primary keys, so we will consider both to be mutually aggregate roots and value objects. This means that when saving A, B as an attached table will also be saved. Conversely, when B is saved as the object, A will also be saved.

In the second situation, there are some differences from the first. When we save Table A, Table B will also be saved. When we save Table B, Table A will not be affected. What is affected is Table B's field aid, which will be modified to A's id, while Table A will not be affected by savable(B), meaning both cannot be mutually aggregate roots and mutually value objects.

Relationship Diagram

We have defined 3 objects respectively, which are primary key to primary key one-to-one, and primary key to non-primary key one-to-one.

Note!!!

Save can only be initiated by aggregate root objects, then value objects will judge whether they need to modify or delete value objects under the aggregate root. It cannot initiate save from value objects to affect the aggregate root

  • Here, with SaveUser as the aggregate root for save, then SaveUserExt and SaveUserAddress are value objects that can be saved
  • With SaveUserExt as the aggregate root for save, then SaveUser and SaveUserAddress are value objects that can be saved
  • With SaveUserAddress as the aggregate root, then SaveUser and SaveUserAddress will not be modified or saved

Why is SaveUser the aggregate root in the SaveUser->SaveUserExt path? Because the condition for judging aggregate root is whether the association relationship selfProperty are all the primary keys of the current object. If selfProperty are all the primary keys of the current object, then the current object is the aggregate root, and the target object is a value object.

Note!!!

savable requires that @EasyQueryTrack and transactions must be enabled. Enable tracking to facilitate modification data so that the framework can sense modification paths. Transactions are required because savable often involves multiple tables, so transactions must be enabled. Internally, it will check whether transactions are enabled

One-to-One Insert Save

Flow Diagram

For this insert operation, we only assigned primary keys to the current data (can be omitted if there's a primary key generator), and did not assign data relationship keys, but the savable mode can automatically help us identify and copy corresponding data, such as the uid property of t_save_user_addr is automatically assigned to 1.

Note: Our save operations in springboot or solon must be performed within the @EasyQueryTrack scope for queries to be tracked, and both include and loadInclude can be considered as paths that the user needs to be saved.
The @Transactional transaction annotation only needs to enable transactions when calling savable execution, otherwise it will report an error, and it doesn't need to include the previous query operation.

One-to-One Cascade Modification

Modify user age and modify user address

Flow Diagram
  • ① User query with address information query, telling the framework that this save path needs to check the user and address path
  • ② Modifying the value object address information will generate corresponding update operation with difference

One-to-One Cascade Dissociation

Flow Diagram

Default dissociation is auto. The framework handles automatically using set null, so we assign null to the include path to trigger target value object dissociation.

Value Object Change

Besides setting the target object to null, we can also replace the original object by creating a new object. Then the original object will dissociate from the aggregate, and the new object will associate with the aggregate root.

Flow Diagram

The original address will dissociate in a set null manner, and the new object will associate in an insert manner

Primary Key Dissociation


    @PostMapping("/remove2")
    @Transactional(rollbackFor = Exception.class)
    @EasyQueryTrack
    public Object remove2() {

        SaveUser saveUser = easyEntityQuery.queryable(SaveUser.class)
                .where(save_user -> {
                    save_user.name().eq("XiaoMing");
                })
                .include(save_user -> save_user.saveUserExt())
                .singleNotNull();
        saveUser.setAge(new Random().nextInt());
        saveUser.setSaveUserExt(null);

        easyEntityQuery.savable(saveUser).executeCommand();
        return "ok";
    }

Error: The framework will check if the target object is dissociating and mutually an aggregate root, then set null dissociation is not allowed

com.easy.query.core.exception.EasyQueryInvalidOperationException: entity:[SaveUser.saveUserExt] targetProperty has key props,cascade cant use set null

Primary Key Dissociate Delete

We change the dissociation method to delete and try again


@Table("t_save_user")
@Data
@EntityProxy
@FieldNameConstants
@EasyAlias("save_user")
public class SaveUser implements ProxyEntityAvailable<SaveUser, SaveUserProxy> {
    @Column(primaryKey = true, primaryKeyGenerator = UUIDPrimaryKey.class)
    private String id;
    private String name;
    private Integer age;
    private LocalDateTime createTime;
    /**
     * User extra information
     **/
    @Navigate(value = RelationTypeEnum.OneToOne,
            selfProperty = {SaveUser.Fields.id},
            targetProperty = {SaveUserExt.Fields.id},
            cascade = CascadeTypeEnum.DELETE)//Modify to cascade delete
    private SaveUserExt saveUserExt;

    /**
     * User address information
     **/
    @Navigate(value = RelationTypeEnum.OneToOne, selfProperty = {SaveUser.Fields.id}, targetProperty = {SaveUserAddress.Fields.uid})
    private SaveUserAddress saveUserAddress;
}

You can see that SaveUserExt can be deleted correctly

DELETE FROM `t_save_user_ext`
WHERE `id` = '1'

UPDATE `t_save_user`
SET `age` = 1926895323
WHERE `id` = '1'

Value Object Ownership Change

eq's ownership change supports arbitrary exchange of value objects of the same object tree depth between different aggregate roots, to achieve object ownership change. However, by default, object ownership change, which is a relatively dangerous operation, is not allowed and needs to be manually allowed by the user.

Object ownership change is relatively complex. Users can jump to the corresponding chapter to view

Contributors

xuejiaming芥子-李显亮
Default Footer
Copyright © 2025 xuejmnet