不标识@TableName、@TableField和@TableID注解会发生什么?

简介: 不标识@TableName、@TableField和@TableID注解会发生什么?

如果不标识 @TableName@TableField@TableId 注解,通常的 ORM 框架会采用一些默认规则来进行映射。以下是一些可能的默认规则:


  1. 表名默认规则: ORM 框架可能会使用实体类的类名,并将其转换为数据库表名。例如,实体类 User 可能默认映射到数据库表 user
  2. 字段名默认规则: ORM 框架通常会将实体类的属性名作为数据库表的列名。例如,实体类中的属性 userName 可能默认映射到数据库表中的列名 user_name
  3. 主键默认规则: ORM 框架可能会将名为 id 的属性默认视为主键,且采用适当的主键生成策略。例如,使用自增长的方式。
  4. 字段存在性默认规则: 如果某个实体类属性在数据库表中不存在,ORM 框架可能会引发异常或忽略该属性。


如果数据库表和实体类的命名规则及结构默认符合上述规则,那么在很多情况下,你可能无需显式地添加这些注解。但是,一旦涉及到不同的命名规则、主键生成策略、字段的存在性等需求,显式地使用这些注解能够提供更细粒度的控制和配置。


标识这些注解能够让你更加灵活地定义数据库表和实体类之间的映射关系,以及控制生成的 SQL 语句。如果你不使用这些注解,框架可能会采用默认规则,但你可能会失去一些自定义配置的机会。


这些就需要继续探索Mybatis啦


相关文章
|
8月前
|
Oracle Java 关系型数据库
JPA主键生成策略介绍
【1月更文挑战第9天】本篇 Huazie 向大家介绍 JPA主键生成策略
144 5
JPA主键生成策略介绍
|
数据库
MybatisPlus中设置自动填充时间@TableField注解的使用
MybatisPlus中设置自动填充时间@TableField注解的使用
878 0
|
6月前
|
存储 数据库
UUID主键生成策略
【7月更文挑战第9天】在分库分表场景中,自增主键不再适用,面试时应提及这一挑战。主键生成策略包括UUID,虽简单但有两弊端:长度过长且非递增。递增主键能优化存储,避免页分裂导致的性能下降。准备时需了解常见策略、创新方案及优化措施。例如,UUID的非递增性可能导致数据库的页分裂和性能影响。
64 3
|
7月前
|
JSON Java 数据库连接
Hibernate中使用@Lob 注解保存String[] 问题
Hibernate中使用@Lob 注解保存String[] 问题
41 2
|
8月前
|
Java 关系型数据库 数据库连接
深入理解 @TableName 和 @TableField 注解
深入理解 @TableName 和 @TableField 注解
310 0
|
数据库
MyBatisPlus中使用@TableField完成字段自动填充
MyBatisPlus中使用@TableField完成字段自动填充
205 0
|
算法 数据库
MyBatisPlus之id生成策略
MyBatisPlus之id生成策略
435 0
|
JSON 数据格式
swagger参数注解,后台使用@RequestBody注解的实体类,但只需要传实体类中的一个属性
这样写的结果会是下面这个样子,导致出现两个参数,一个实体类传参类型是json格式,一个是注解中写的属性。
|
Java 关系型数据库 数据库连接
MyBatis 处理长字段(long varchar)
MyBatis 处理长字段(long varchar)
243 0
MyBatis 处理长字段(long varchar)
|
算法 NoSQL 数据库
【mybatis-plus】主键id生成、字段自动填充
【mybatis-plus】主键id生成、字段自动填充
【mybatis-plus】主键id生成、字段自动填充