Interpretation of mybatisplus mapping

Table of contents

automatic mapping

table mapping

field mapping

field failure 

view properties


The reason why the Mybatis framework can simplify database operations is because of its internal mapping mechanism, which encapsulates data through automatic mapping. As long as we comply with the mapping rules, we can quickly and efficiently complete the realization of SQL operations. Since MybatisPlus is an enhancement tool based on Mybatis, it also has such mapping rules.

Let's first look at the automatic mapping rules.

automatic mapping

  • [1] Table name and entity class name mapping -> table name user entity class name User
  • [2] Field name and entity class attribute name mapping -> field name name entity class attribute name name
  • [3] Mapping of field name underline naming method and entity class attribute small hump naming method -> field name user_email entity class attribute name userEmail

MybatisPlus supports this mapping rule, which can be set through configuration

map-underscore-to-camel-case: true 表示支持下划线到驼峰的映射
map-underscore-to-camel-case: false 表示不支持下划线到驼峰的映射

It can be configured in the application.yml file:

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true

table mapping

Specify the mapped database table name through the @TableName () annotation, and it will be mapped according to the specified table name. For example: at this time, change the database table name to study_user. To complete the mapping between the table name and the entity class name, you need to change the entity class name Also specify as study_user

@Data
@AllArgsConstructor
@NoArgsConstructor
@TableName("study_user")
public class User {
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

If there are many entity classes, corresponding to many tables in the database, we don’t need to configure each one in turn, we only need to configure a global setting, which will add a specified prefix to each entity class name, here we demonstrate in application The effect of .yml global configuration

mybatis-plus:
  global-config:
    db-config:
      table-prefix: study_

The prefix of the table name is study_ 

field mapping

Under what circumstances will the field mapping be changed?

[1] When the attributes of the database field and the table entity class are inconsistent, we can use the @TableField () annotation to change the mapping between the field and the attribute, so that the name in the annotation is consistent with the table field.
For example: at this time, the name of the database field we Changed to username, when splicing SQL according to the attributes of the entity class, the name username specified in @TableField () will be used for splicing to complete the query

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableField("username")
    private String name;
   }

The SQL statement at this time is like this

SELECT id,username AS name,email FROM study_user

[2] The attributes of the database fields and table entity classes are consistent. When the framework splices SQL statements, it will use the attribute names to directly splice SQL statements, for example:

SELECT  id,username AS name,age,email,desc  FROM study_user

When this statement is directly queried, an error will occur

Error querying database.  Cause: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'desc  FROM study_user' at line 1

The reason is that desc is a keyword and cannot be directly used in SQL queries. To solve this problem, you need to add a `` symbol to the desc field to make it not a keyword to complete the query. The root of this problem is also to change The field name of the generated SQL statement, that is, we need to change the attribute name of the entity class through @TableField () , and change desc to `desc`, which can solve this problem

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableField("`desc`")
    private String desc;
}

field failure 

When there is a field in the database that you do not want to be queried, we can hide this field through @TableField(select = false) , then when splicing SQL statements, this field will not be spliced

For example: if you do not want to display age information, you can add this annotation to the age attribute to hide this field

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableField(select = false)
    private Integer age;
}

The generated SQL statement is as follows. By querying the generated SQL statement, it is found that the age field is not spliced

view properties

In actual development, some fields do not need to be stored in the database, but they need to be displayed. The need to display means that this field needs to exist in the entity class. We call these fields that exist in the entity class but do not exist in the database, called view fields.

According to previous experience, the framework will splicing the attributes in the entity class as query fields by default. Let's think about whether such view fields can be used as query conditions, but the display cannot. Because there is no such field in the database, if the query field contains this field, the SQL statement will have problems. We use @TableField(exist = false) to remove this field and prevent it from being used as a query field.

@Data
@AllArgsConstructor
@NoArgsConstructor
public class User {
    @TableField(exist = false)
    private Integer online;
}

Guess you like

Origin blog.csdn.net/m0_62436868/article/details/131900179