hibernate-mapping参数详解

hibernate-mapping参数详解

Mapping 文件parsing:
一、hibernate-mapping
1.default-access (可选 - 默认为 property): Hibernate用来访问属性的策略。可以通过实现PropertyAccessor接口 自定义。
2.default-lazy (可选 - 默认为 true): 指定了未明确注明lazy属性的Java属性和集合类， Hibernate会采取什么样的默认加载风格。
3.auto-import (可选 - 默认为 true): 指定我们是否可以在查询语言中使用非全限定的类名（仅限于本映射文件中的类）。 假若你有两个持久化类，它们的非全限定名是一样的（就是两个类的名字一样，所在的包不一样）， 你应该设置auto-import="false"。假若说你把一个“import过”的名字同时对应两个类， Hibernate会抛出一个异常。
注 ：操作级联（cascade）关系。可选值：
all : 所有情况下均进行级联操作。
none：所有情况下均不进行级联操作。
save-update:在执行save-update时进行级联操作。
delete：在执行delete时进行级联操作。
级联（cascade）在Hibernate映射关系中是个非常重要的概念。它指的是当主控方执行操作时，关联对象（被动方）是否同步执行同一操作。如对主控对象调用save-update或delete方法时，是否同时对关联对象（被动方）进行Text Nsave-update或delete。例如，当用户（TUser）被更新或者删除时，其所关联的组（TGroup）不应被修改或者删除，因此，级联关系设置为none。
                     
       
1.unsaved-value (可选 - 默认为一个字段判断（sensible）的值): 一个特定的标识属性值，用来标志该实例是刚刚创建的，尚未保存。 这可以把这种实例和从以前的session中装载过（可能又做过修改--译者注） 但未再次持久化的实例区分开来。
2.access (可选 - 默认为property): Hibernate用来访问属性值的策略。
3.关键说一下：Key Generator  主键产生器
可选项说明：
1) Assigned
主键由外部程序负责生成，无需Hibernate参与。
2) hilo
通过hi/lo 算法实现的主键生成机制，需要额外的数据库表保存主
键生成历史状态。
3) seqhilo
与hilo 类似，通过hi/lo 算法实现的主键生成机制，只是主键历史
状态保存在Sequence中，适用于支持Sequence的数据库，如Oracle。
4) increment
主键按数值顺序递增。此方式的实现机制为在当前应用实例中维持
一个变量，以保存着当前的最大值，之后每次需要生成主键的时候
将此值加1作为主键。
这种方式可能产生的问题是：如果当前有多个实例访问同一个数据
库，那么由于各个实例各自维护主键状态，不同实例可能生成同样
的主键，从而造成主键重复异常。因此，如果同一数据库有多个实
例访问，此方式必须避免使用。
5) identity
采用数据库提供的主键生成机制。如DB2、SQL Server、MySQL
中的主键生成机制。
6) sequence
采用数据库提供的sequence 机制生成主键。如Oralce 中的
Sequence。
7) native
由Hibernate根据底层数据库自行判断采用identity、hilo、sequence
其中一种作为主键生成方式。
8) uuid.hex
由Hibernate基于128 位唯一值产生算法生成16 进制数值（编码后
以长度32 的字符串表示）作为主键。
9) uuid.string
与uuid.hex类似，只是生成的主键未进行编码（长度16）。在某些
数据库中可能出现问题（如PostgreSQL）。
10) foreign
使用外部表的字段作为主键。
一般而言，利用uuid.hex 方式生成主键将提供最好的性能和数据库平台适
应性。
 
(1)
name (可选): 持久化类（或者接口）的Java全限定名。 如果这个属性不存在，Hibernate将假定这是一个非POJO的实体映射。 (2)
table (可选 - 默认是类的非全限定名): 对应的数据库表名。 (3)
discriminator-value (可选 - 默认和类名一样): 一个用于区分不同的子类的值，在多态行为时使用。它可以接受的值包括 null 和 not null。 (4)
mutable (可选，默认值为true): 表明该类的实例是可变的或者可变的。 (5)
schema (可选): 覆盖在根元素中指定的schema名字。 (6)
catalog (可选): 覆盖在根元素中指定的catalog名字。 (7)
proxy (可选): 指定一个接口，在延迟装载时作为代理使用。 你可以在这里使用该类自己的名字。 (8)
dynamic-update (可选, 默认为 false): 指定用于UPDATE 的SQL将会在运行时动态生成，并且只更新那些改变过的字段。 (9)
dynamic-insert (可选, 默认为 false): 指定用于INSERT的 SQL 将会在运行时动态生成，并且只包含那些非空值字段。 (10)
select-before-update (可选, 默认为 false): 指定Hibernate除非确定对象真正被修改了（如果该值为true－译注），否则不会执行SQL UPDATE操作。在特定场合（实际上，它只在一个瞬时对象（transient object）关联到一个 新的session中时执行的update()中生效），这说明Hibernate会在UPDATE 之前执行一次额外的SQL SELECT操作，来决定是否应该执行 UPDATE。 (11)
polymorphism（多态） (可选, 默认值为 implicit (隐式) ): 界定是隐式还是显式的使用多态查询（这只在Hibernate的具体表继承策略中用到－译注）。 (12)
where (可选) 指定一个附加的SQLWHERE 条件， 在抓取这个类的对象时会一直增加这个条件。 (13)
persister (可选): 指定一个定制的ClassPersister。 (14)
batch-size (可选,默认是1) 指定一个用于 根据标识符（identifier）抓取实例时使用的"batch size"（批次抓取数量）。 (15)
optimistic-lock（乐观锁定） (可选，默认是version): 决定乐观锁定的策略。 (16)
lazy (optional): 通过设置lazy="false"， 所有的延迟加载（Lazy fetching）功能将未被激活（disabled）。 (17)
entity-name (可选): Hibernate3允许一个类进行多次映射（ 默认情况是映射到不同的表），并且允许使用Maps或XML代替Java层次的实体映射 （也就是实现动态领域模型，不用写持久化类－译注）。 更多信息请看第 4.4 节 “动态模型(Dynamic models)” and 第 18 章 XML映射。 (18)
catalog (可选): 这个类对应的表所使用的数据库catalog名称。 (19)
check (可选): 这是一个SQL表达式， 用于为自动生成的schema添加多行（multi-row）约束检查。 (20)
rowid (可选): Hibernate可以使用数据库支持的所谓的ROWIDs，例如： Oracle数据库，如果你设置这个可选的rowid， Hibernate可以使用额外的字段rowid实现快速更新。ROWID是这个功能实现的重点， 它代表了一个存储元组（tuple）的物理位置。 (21)
subselect (可选): 它将一个不可变（immutable）并且只读的实体映射到一个数据库的 子查询中。它用于实现一个视图代替一张基本表，但是最好不要这样做。更多的介绍请看下面内容。 (22)
abstract (可选): 用于在的继承结构 （hierarchies）中标识抽象超类。
若指明的持久化类实际上是一个接口，这也是完全可以接受的。 之后你可以用来指定该接口的实际实现类。 你可以持久化任何static（静态的）内部类。 你应该使用标准的类名格式来指定类名，比如：Foo$Bar。
不可变类，mutable="false"不可以被应用程序更新或者删除。 这可以让Hibernate做一些小小的性能优化。
可选的proxy属性允许延迟加载类的持久化实例。 Hibernate开始会返回实现了这个命名接口的CGLIB代理。当代理的某个方法被实际调用的时候， 真实的持久化对象才会被装载。参见下面的“用于延迟装载的代理”。
Implicit (隐式)的多态是指，如果查询时给出的是任何超类、该类实现的接口或者该类的 名字，都会返回这个类的实例；如果查询中给出的是子类的名字，则会返回子类的实例。 Explicit （显式）的多态是指，只有在查询时给出明确的该类名字时才会返回这个类的实例； 同时只有在这个的定义中作为 或者出现的子类，才会可能返回。 在大多数情况下，默认的polymorphism="implicit"都是合适的。 显式的多态在有两个不同的类映射到同一个表的时候很有用。（允许一个“轻型”的类，只包含部分表字段）。
persister属性可以让你定制这个类使用的持久化策略。 你可以指定你自己实现 org.hibernate.persister.EntityPersister的子类，你甚至可以完全从头开始编写一个 org.hibernate.persister.ClassPersister接口的实现， 比如是用储存过程调用、序列化到文件或者LDAP数据库来实现。 参阅org.hibernate.test.CustomPersister，这是一个简单的例子 （“持久化”到一个Hashtable）。
请注意dynamic-update和dynamic-insert的设置并不会继承到子类， 所以在或者元素中可能 需要再次设置。这些设置是否能够提高效率要视情形而定。请用你的智慧决定是否使用。
使用select-before-update通常会降低性能。如果你重新连接一个脱管（detache）对象实例 到一个Session中时，它可以防止数据库不必要的触发update。 这就很有用了。
如果你打开了dynamic-update，你可以选择几种乐观锁定的策略：
version（版本检查） 检查version/timestamp字段
all（全部） 检查全部字段
dirty（脏检查）只检察修改过的字段
none（不检查）不使用乐观锁定
我们非常强烈建议你在Hibernate中使用version/timestamp字段来进行乐观锁定。 对性能来说，这是最好的选择，并且这也是唯一能够处理在session外进行操作的策略（例如： 在使用Session.merge()的时候）。
对Hibernate映射来说视图和表是没有区别的，这是因为它们在数据层都是透明的（ 注意：一些数据库不支持视图属性，特别是更新的时候）。有时你想使用视图，但却不能在数据库 中创建它（例如：在遗留的schema中）。这样的话，你可以映射一个不可变的（immutable）并且是 只读的实体到一个给定的SQL子查询表达式：
            select item.name, max(bid.amount), count(*)        from item        join bid on bid.item_id = item.id        group by item.name                    ...
定义这个实体用到的表为同步（synchronize），确保自动刷新（auto-flush）正确执行， 并且依赖原实体的查询不会返回过期数据。在属性元素 和一个嵌套映射元素中都可见。
 
5 Persister
自定义持久类实现类类名。如果系统中还需要Hibernate 之外的持久层实现机制，如通过存储过程得到目标数据集，甚至从LDAP中获取数据来填充我们的POJO。
6 Enable proxies
是否使用代理（用于延迟加载[Lazy Loading]）。
7 Dynamic Update
如果选定，则生成Update SQL 时不包含未发生变动的字段属性，这样可以在一定程度上提升SQL执行效能。
8 Mutable
类是否可变，默认为选定状态（可变）。如果不希望应用程序对此类对应的数据记录进行修改（如对于数据库视图），则可将取消其选定状态，之后对此类的Delete和Update操作都将失效。
9 Implement the Lifecyle interface
是否实现Lifecyle接口。Lifecyle接口提供了数据固化过程中的控制机制，通过实现Lifecyle接口，我们可以在数据库操作中加入回调（Call Back）机制，如在数据库操作之前，之后触发指定操作。
10 Implement the Validatable interface
是否实现Validatable接口。通过实现Validatable接口，我们可以在数据被固化到数据库表之前对其合法性进行验证。
值得注意的是，通过实现Lifecyle接口，我们同样可以在数据操作之前验证数据合法性，不同的是，Validatable 接口中定义的validate 方法可能会被调用多次，因此设计中应避免在Validatable 接口的validate 方法实现中加入业务逻辑的验证。
 
@@ 关于unsaved-value
在非显示数据保存时，Hibernate将根据这个值来判断对象是否需要保存。所谓显式保存，是指代码中明确调用session 的save、update、saveOrupdate方法对对象进行持久化。如：session.save(user);
    而在某些情况下，如映射关系中，Hibernate 根据级联（Cascade）关系对联接类进行保存。此时代码中没有针对级联对象的显示保存语句，需要Hibernate 根据对象当前状态判断是否需要保存到数据库。此时，Hibernate即将根据unsaved-value进行判定。首先Hibernate会取出目标对象的id。之后，将此值与unsaved-value进行比对，如果相等，则认为目标对象尚未保存，否则，认为对象已经保存，无需再进行保存操作。如：user对象是之前由hibernate从数据库中获取，同时，此user对象的若干个关联对象address 也被加载，此时我们向user 对象新增一个address 对象，此时调用session.save(user)，hibernate会根据unsaved-value判断user对象的数个address关联对象中，哪些需要执行save操作，而哪些不需要。对于我们新加入的address 对象而言，由于其id（Integer 型）尚未赋值，因此为null，与我们设定的unsaved-value（null）相同，因此hibernate将其视为一个未保存对象，将为其生成insert语句并执行。
    这里可能会产生一个疑问，如果“原有”关联对象发生变动（如user的某个“原有”的address对象的属性发生了变化，所谓“原有”即此address对象已经与user相关联，而不是我们在此过程中为之新增的），此时id值是从数据库中读出，并没有发生改变，自然与unsaved-value（null）也不一样，那么Hibernate是不是就不保存了？上面关于PO、VO 的讨论中曾经涉及到数据保存的问题，实际上，这里的“保存”，实际上是“insert”的概念，只是针对新关联对象的加入，而非数据库中原有关联对象的“update”。所谓新关联对象，一般情况下可以理解为未与Session 发生关联的VO。而“原有”关联对象，则是PO。
    如上面关于PO、VO的讨论中所述：对于save操作而言，如果对象已经与Session相关联（即已经被加入Session的实体容器中），则无需进行具体的操作。因为之后的Session.flush过程中，Hibernate会对此实体容器中的对象进行遍历，查找出发生变化的实体，生成并执行相应的update语句。
@@Inverse和Cascade
Inverse，直译为“反转”。在Hibernate语义中，Inverse指定了关联关系中的方向。关联关系中，inverse=”false”的为主动方，由主动方负责维护关联关系。具体可参见一对多关系中的描述。
而Cascade，译为“级联”，表明对象的级联关系，如TUser的Cascade设为all，就表明如果发生对user对象的操作，需要对user所关联的对象也进行同样的操作。如对user对象执行save操作，则必须对user对象相关联的address也执行save操作。初学者常常混淆inverse和cascade，实际上，这是两个互不相关的概念。Inverse指的是关联关系的控制方向，而cascade指的是层级之间的连锁操作。
锁（locking）
业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算处理中，我们希望针对某个cut-off时间点的数据进行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。
Hibernate支持两种锁机制：即通常所说的“悲观锁（Pessimistic Locking）”和“乐观锁（Optimistic Locking）”。
悲观锁（Pessimistic Locking）
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
一个典型的倚赖数据库的悲观锁调用：
select * from account where name=”Erica” for update
这条sql 语句锁定了account 表中所有符合检索条件（name=”Erica”）的记录。
本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。
Hibernate的悲观锁，也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁：
String hqlStr =
"from TUser as user where user.name=\'Erica\'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); //加锁
List userList = query.list();//执行查询，获取数据
query.setLockMode对查询语句中，特定别名所对应的记录进行加锁（我们为
TUser类指定了一个别名“user”），这里也就是对返回的所有user记录进行加锁。
观察运行期Hibernate生成的SQL语句：
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id
as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
from t_user tuser0_ where (tuser0_.name=\'Erica\' ) for update
这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。
Hibernate的加锁模式有：
? LockMode.NONE ： 无锁机制。
? LockMode.WRITE ：Hibernate在Insert和Update记录的时候会自动
获取。
? LockMode.READ ： Hibernate在读取记录的时候会自动获取。
以上这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update
过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
? LockMode.UPGRADE ：利用数据库的for update子句加锁。
? LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for
update nowait子句实现加锁。
上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode
Query.setLockMode
Session.lock
注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会
真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update
子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。
乐观锁（Optimistic Locking）
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依
靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库
性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进
行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过
程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作
员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几
百上千个并发，这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本
（Version）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于
数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来
实现。
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提
交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据
版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个
version字段，当前值为1；而当前帐户余额字段（balance）为$100。
1 操作员A 此时将其读出（version=1），并从其帐户余额中扣除$50
（$100-$50）。
2 在操作员A操作的过程中，操作员B也读入此用户信息（version=1），并
从其帐户余额中扣除$20（$100-$20）。
3 操作员A完成了修改工作，将数据版本号加一（version=2），连同帐户扣
除后余额（balance=$50），提交至数据库更新，此时由于提交数据版本大
于数据库记录当前版本，数据被更新，数据库记录version更新为2。
4 操作员B完成了操作，也将版本号加一（version=2）试图向数据库提交数
据（balance=$80），但此时比对数据库记录版本时发现，操作员B提交的
数据版本号为2，数据库记录当前版本也为2，不满足“提交版本必须大于记
录当前版本才能执行更新“的乐观锁策略，因此，操作员B 的提交被驳回。
这样，就避免了操作员B 用基于version=1 的旧数据修改的结果覆盖操作
员A的操作结果的可能。
从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员A
和操作员B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系
统整体性能表现。
需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局
限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户
余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在
系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如
将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途
径，而不是将数据库表直接对外公开）。
Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数
据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的
生产力。
Hibernate中可以通过class描述符的optimistic-lock属性结合version
描述符指定。
现在，我们为之前示例中的TUser加上乐观锁机制。
1． 首先为TUser的class描述符添加optimistic-lock属性：
……
optimistic-lock属性有如下可选取值：
? none
无乐观锁
? version
通过版本机制实现乐观锁
? dirty
通过检查发生变动过的属性实现乐观锁
? all
通过检查所有属性实现乐观锁
其中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也
是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机
制。因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。
2． 添加一个Version属性描述符
……
注意version节点必须出现在ID节点之后。
这里我们声明了一个version属性，用于存放用户的版本信息，保存在TUser表的
version字段中。
此时如果我们尝试编写一段代码，更新TUser表中记录数据，如：
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); //更新UserType字段
tx.commit();
每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。
而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为Erica 的用
户进行操作，以模拟并发更新时的情形：
Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Erica"));
List userList = criteria.list();
List userList2 = criteria2.list();
TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();
执行以上代码，代码将在tx.commit()处抛出StaleObjectStateException异
常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我
们就可以在乐观锁校验失败时进行相应处理。