Skip to main content

如何在Hibernate中转义SQL中的关键字

Submitted by taotao on Mon, 06/03/2019 - 17:49

概述

        我们在实际的项目中,可能会将一些SQL的关键字作为实体的属性名,我们可能会使用如下的数据库:MySQL 、PostgreSQL 、SqlServer,每个数据库都有各自不同的保留关键字,因此如果我们要将这些关键字作为实体属性的名称,或者数据库的表名,数据库就会报错。如何解决这个问题?我们可以用如下的两个方法。

在实体定义的时候通过 标注的方式指定

我们如果有如下的实体定义

Tags

Hibernate中的实体状态切换

Submitted by taotao on Sun, 06/02/2019 - 16:24

概述

        我们在使用ORM工具时,直接和实体进行交互,就可以操作数据库,不再需要写 SQL语句。但是Hibernate不是软件饮弹,我们还是需要关注它生成出来SQL。那么在一次操作的过程中实体会经历哪些状态?各个状态又有哪些含义和作用?

详细解释

Transient

         一个对象刚创建时的状态,这个状态下的对象还没有映射为数据库中的记录。只有调用Session.save()或者 EntityManager.persist()方法的时候,状态会切换为Managed。

Managed

          刚创建的对象通过调用Session.save()或者EntityManager.persist()方法的时候,就会从 Transient状态切换到Managed状态,该状态下的对象的任何属性值改变都会在Session.flush()的时候,自动同步到数据库中,因此我们不需要手动执行insert/update/delete这些方法。

Tags

如何在Hibernate中配置MySQL主键自动生成策略

Submitted by taotao on Mon, 05/27/2019 - 12:18

概述

        我们在使用Hibernate操作MySQL数据库的时候,会遇到主键配置的问题,因为MySQL没有提供 像Oracle或者PostgreSQL的sequence机制。因此我们如果使用基于Sequence的机制生成主键时,Hibernate会自动为我们生成一个Hibernate_Sequence的表,所以当我们要创建实体的时候,Hibernate会首先从这个表里获取当前值,然后将累加后的值作为新对象的ID值,保存到数据库中。同时 MySQL本身提供主键自增长机制,我们可以结合Hibernate主键自动生成机制实现在保存新对象的时候,自动插入新的ID值,不需要在创建对象的时候明确指定ID。下面这两种的方式的详细介绍和差异对比分析。

利用MySQL的主键自增长机制创建对象

详细描述

步骤1,在创建 MySQL表的主键的时候,需要确保主键是自增长的,可以按照如下的方式设置: 

Tags

JPA中的OneToMany和ManyToOne的最佳实践

Submitted by taotao on Sun, 05/26/2019 - 12:49

概述

        我们在使用JPA的时候,会使用OneToMany表示对象之间的一对多的关系,ManyToOne表示多对一的关系。多对一和一对多只是对象关系中的正面描述和反面描述,在JPA中不一样的定义方法会有不同的SQL生成,对性能会有比较大的影响。比如我们举一个例子:一个学校会有很多的学生,很多学生都会在一个学校上学,那么我们应该会设计一个父对象School和一个子对象Student,School实体会和和Student之间有一对多的关联关系,Student实体和School实体有多对一的关联关系。在JPA中对于上述的场景描述我们会有三个不同的做法:

  1. 在父对象中使用@OneToMany建立和子对象的关系关系
  2. 在父对象中使用@OneToMany和@JoinColumn来建立和子对象的关系
  3. 建立双向关系,在父对象中使用OneToMany,在子对象中使用ManyToOne
  4. 在子对象中使用ManyToOne建立和父对象的联系

 

Tags

谈谈对组织的一些认知

Submitted by taotao on Sat, 05/25/2019 - 13:58

         在原始社会,人们是以部落的形式集合在一起生活,因为在那个年代,一个人是没有办法在原始环境里生活,大家必须集合在一起,互相帮组,才能抵抗恶劣自然环境。在现代社会,好像我们不需要再像原始部落那样的方式生活了, 毕竟科技发展了,我们只需要遵循经济规律,一个人也可以独立生活的很好。但是在其他方面我们依然需要依靠集体的力量完成某些事情。

        现在的社会是把人根据目的进行了各种形式的部落划分,比如学生在学校里上学,学校就是一个部落,为了可以高效的生产出合格的工人、工程师、作家、律师等等,比如一个保洁公司,整合了社会上的闲散的劳动力,然后对外宣传可以帮任何个人组织提供保洁服务,比如一个户外登山团队,为了在登山的时候,彼此可以提供帮组,并交流分享登山的经验,他们聚合起来形成一个民间组织,例子还有很多不再一一举出,那么原始部落时期的人为了生存这个最基本的生存的目的而聚集在一起,现代的社会,我们由于各种利益,目的聚合在一起了,也是和原始部落是同一个性质的。那么这样说明了不管多少年的发展,人这个动物是离不开组织团体的。

Tags

关于真理的问题

Submitted by taotao on Thu, 05/23/2019 - 12:03

         真理这个词好像理我们每个人都很遥远,我们平常的生活中好像没有什么事情是和真理有关系的。因为我们对于真理的定义也就决定了我们是如何认知真理的,如果我们把真理定义成是学术科研中的某个发现,可能我们会倾向认为真理是和学术研究、自然科学有关系,不会认为和我们的平时生活有什么联系。

Tags

Docker之间的通信方式

Submitted by taotao on Wed, 05/22/2019 - 12:06

概述

我们可以将服务发布到Docker中,然后发布Docker到各个环境,比如开发、测试、生产环境,不再需要像以前那么麻烦,需要一个个的环境进行配置,经常会为了环境之间的差异,花费大量的时间去排查问题,所以使用 Docker提高了我们的研发交付的效率。但是在使用Docker的时候,我们可能会碰到一个场景,那就是服务A需要访问服务B,如果这两个服务都是部署在Docker中,问题就变为我们就需要能够让这两个docker容器进行通信,为了要让这两个Docker容器进行通信,我们就需要将这两个docker都加入到同一个网络中,这个网络可以是虚拟的网络,也可以是实际的物理网络,具体如何操作详情见下文。

利用物理网络进行通信的介绍

如果要通过实际的物理网络进行通信,那么我在启动docker的时候,会有如下的写法:

docker run -d --name serviceA -p 80:8080 serviceA

这就将serviceA在docker内服务的8080端口映射到宿主机器的80端口上,这样服务A和服务B之间就可以通过宿主机的网络进行通信,服务B以如下的方式启动:

微服务中的API编织问题

Submitted by taotao on Thu, 05/16/2019 - 21:43

问题概述

在最近的工作中,碰到了一个同事反馈的问题,就是说我们目前在使用微服务的概念设计系统的架构,那么每个服务都是一个业务边界比较垂直服务,打个比方我们商城中有订单服务、商品服务、促销服务、评论服务,那么问题来了,比如我们在商品的详情页面需要聚合来自商品、评论、促销等服务的数据之后,才能返回商品详情页所需要的数据,这么多的微服务,我们需要在商品详情服务中每次有新的请求过来时,每次都调用一遍吗?如果每次都调用一遍,那么这些服务的网络通信开销会很大,而且每次都要对数据做大量的集合遍历计算,对性能会产生很严重的影响,所以我们需要找到一种方式,在微服务的架构设计下,能够高效的提供数据给商品详情服务。

如何解决

API网关模式

如果聚合这些数据?有两个方式,其中之一就是通过利用API网关聚合多个服务之间的数据,然后再给商城的商品详情服务使用。API网关可以将数据缓存起来,提升效率。 具体的做法可以参考下图:

解决docker镜像耗尽本地磁盘满的问题

Submitted by taotao on Sun, 05/05/2019 - 17:54

概述

在使用docker的过程中,需要经常构建镜像,本地构建的镜像和从外部拉取的镜像就会慢慢耗尽本地的磁盘,本地磁盘被 耗尽就会导致镜像构建失败。

解决办法

docker默认是使用的是 /var/lib/docker目录,因为这个目录不是主目录,所以它的存储空间就不大。 通过如下的办法将docker的存储目录调整到主目录下去:

  1. 备份/var/lib/docker目录
mv /var/lib/docker /var/lib/docker_bak

2. 在主目录下创建一个空目录,并将docker的存储目录 软链到该目录下

mkdir ~/docker-server
cd /var/lib 
ln -s ~/docker-server docker 

通过如上步骤就可以将docker的存储目录调整到主目录下,避免镜像生成到空间小的分区中。 

Tags