isAssignableFrom isAssignableFrom 是用来判断一个类Class1和另一个类Class2是否相同或是另一个类的超类或接口。 通常调用格式是 Class1.isAssignableFrom(Class2) 调用者和参数都是 java.lang.Class 类型。 而 instanceof 是用来判断一个对象实例是否是一个类或接口的或其子类子接口的实例。 格式是: oo instanceof TypeName 第一个参数是对象实例名，第二个参数是具体的类名或接口名，例如 String，InputStream。 用下面的代码进行测试，我们就可以发现他们的不同之处
SKU http://baike.baidu.com/view/276922.htm SKU=Stock Keeping Unit (库存量单位) 。即库存进出计量的单位,可以是以件,盒,托盘等为单位。SKU这是对于大型连锁超市DC (配送中心) 物流管理的一个必要的方法。现在已经被我们引申为产品统一编号的简称,每种产品均对应有唯一的SKU号。单品: 对一种商品而言,当其品牌、型号、配置、等级、花色、包装容量、单位、生产日期、保质期、用途、价格、产地等属性与其他商品存在不同时,可称为一个单品。[1] 概述 编辑 SKU=Stock Keeping Unit(库存量单位),即库存进出计量的单位,可以是以件,盒,托盘等为单位。SKU这是对于大型连锁超市DC (配送中心) 物流管理的一个必要的方法。 流程图 流程图 当下已经被我们引申为产品统一编号的简称,每种产品均对应有唯一的SKU号。[1] 针对电商而言,SKU有另外的注解: SKU是指一款商品,每款都有出现一个SKU,便于电商品牌识别商品。 一款商品多色,则是有多个SKU,例: 一件衣服,有红色、白色、蓝色,则SKU编码也不相同,如相同则会出现混淆,发错货。 补: 英文全称为 stock keeping unit, 简称SKU,定义为保存库存控制的最小可用单位,例如纺织品中一个SKU通常表示: 规格、颜色、款式。 STOCK KEEP UNIT.这是客户拿到商品放到仓库后给商品编号,归类的一种方法. 通常是SKU#是多少多少这样子. 还有的译为存货单元\库存单元\库存单位\货物存储单位\存货保存单位\单元化单位\单品\品种,基于业务还有的是最小零售单位\最小销售单位\最小管理单位\库存盘点单位等；专业物流术语解释为"货格"。 换言之,有助于理解: 首先我们应当了解单品的定义,即指包含特定的自然属性与社会属性的商品种类。对一种商品而言,当其品牌、型号、配置、等级、花色、包装容量、单位、生产日期、保质期、用途、价格、产地等属性与其他商品存在不同时,可称为一个单品。在连锁零售门店中有时称单品为一个SKU (中文译为最小存货单位,例如纺织品中一个SKU通常表示规格,颜色,款式) 。当然,单品与传统意义上的"品种"的概念是不同的,用单品这一概念可以区分不同商品的不同属性,从而为商品采购、销售、物流管理、财务管理以及POS系统与MIS系统的开发提供极大的便利。例如: 单听销售的可口可乐是一个单品SKU,而整扎销售的可口可乐又是一个单品,这两个单品在库存管理和销售是不一样的。而在传统意义上的品种听装的可口可乐是一个品种,不管其销售模式是什么样的。 我们不难看出,无论是国外还是国内的定义和解释中,基本上是三个概念: 品项、编码、单位。 这三个概念代表了三个方面: 品项,品项可以结合上面关于单品、SKU和品种的解释理解。也就是只要属性有不同,那么就是不同的品项 (SKU) 。可以说这是SKU看作是一种产品的角度来分析理解的。属性有很多种,大家容易理解是品牌、型号、配置、等级、花色、生产日期、保质期、用途、价格、产地等,因为他们可以很直观的区分开来；但是包装容量、单位、存放地等就不是那么容易了——难道一支放到一箱,一箱放到一个托盘就不是这个产品了？同样的产品放到亚洲和美洲就不一样了？也就是说同样的产品只要在人们对其进行保存、管理、销售、服务上有不同的方式,那么它 (SKU) 就不再是相同的了。 编码,这个概念是基于信息系统和货物编码管理来说的,用"品项"中介绍为,不同的品项 (SKU) 就有不同的编码。这样,我们才可以依照不同的SKU数据来分析库存、销售状况。当你使用物流或者ERP系统的时候,你会发现SKU#: 12356这样的文本框。长时间这样的状况让很多朋友都认为,SKU就是产品的编码了。但是这里的产品如"品项"所说,并非是一个泛泛的产品的概念,而是很精确的产品概念。 单位,基本上就是基于管理来说的吧,这个名字上是数字化管理方式的产物。但是这里的单位和我们平时的"单位"有什么区别呢？看看产品的包装单位的不同,SKU就不同。也就是说,精确到SKU的管理方式才能适应当下的物流竞争,其实信息系统的使用对它产生了很大的影响。没有精确的编码来区分相同产品的不同SKU就很难进行单位化到SKU的管理方式。
JPA JPQL http://flowercat.iteye.com/blog/667773 max result entityManager.createQuery(SQL_QUERY).setParameter(arg0,arg1).setMaxResults(10).getResultList();``` JPQL就是一种查询语言,具有与 SQL 相 类似的特征, JPQL 是完全面向对象的,具备继承、多态和关联等特性,和hibernate HQL很相似。 查询语句的参数 JPQL 语句支持两种方式的参数定义方式 : 命名参数和位置参数 。 。在同一个查 询语句中只允许使用一种参数定义方式。 命令参数的格式为: " : + 参数 名" 例: Query query = em.createQuery(“select p from Person p where p.personid=:Id “); query.setParameter(“Id”,new Integer(1)); 位置参数的格式为” ?+ 位置编号” 例: Query query = em.createQuery(“select p from Person p where p.personid=?1 “); query.setParameter(1,new Integer(1)); 如果你需要传递 java.util.Date 或 java.util.Calendar 参数进一个参数查询 ,你需要使用一个特殊的 setParameter() 方法 ,相关的 setParameter 方法定义如下: public interface Query ...
Java转型(向上或向下转型)upcast)和向下转型(downcast) 在Java编程中经常碰到类型转换,对象类型转换主要包括向上转型和向下转型。 5.13.1 向上转型 我们在现实中常常这样说: 这个人会唱歌。在这里,我们并不关心这个人是黑人还是白人,是成人还是小孩,也就是说我们更倾向于使用抽象概念"人"。再例如,麻雀是鸟类的一种 (鸟类的子类) ,而鸟类则是动物中的一种 (动物的子类) 。我们现实中也经常这样说: 麻雀是鸟。这两种说法实际上就是所谓的向上转型,通俗地说就是子类转型成父类。这也符合Java提倡的面向抽象编程思想。来看下面的代码: package a.b; public class A { public void a1() { System.out.println(“Superclass”); } } A的子类B: package a.b; public class B extends A { public void a1() { System.out.println(“Childrenclass”); //覆盖父类方法 } public void b1(){} //B类定义了自己的新方法 } C类: package a.b; public class C { public static void main(String[] args) { A a = new B(); //向上转型 a.a1(); } } 如果运行C,输出的是Superclass 还是Childrenclass？不是你原来预期的Superclass,而是Childrenclass。这是因为a实际上指向的是一个子类对象。当然,你不用担心,Java虚拟机会自动准确地识别出究竟该调用哪个具体的方法。不过,由于向上转型,a对象会遗失和父类不同的方法,例如b1()。有人可能会提出疑问: 这不是多此一举吗？我们完全可以这样写: B a = new B(); a.a1(); 确实如此！但这样就丧失了面向抽象的编程特色,降低了可扩展性。其实,不仅仅如此,向上转型还可以减轻编程工作量。来看下面的显示器类Monitor: package a.b; public class Monitor{ ...
detached entity passed to persist 病理特征: Caused by: org.hibernate.PersistentObjectException: detached entity passed to persist: com.xxx.Xxx 简单地说，发生此异常即是一个游离的对象要被持久化(save)时，其ID既要ORM框架为它生成ID值，而此实体的ID却已然有值。对于新手容易出现此异常，但一些有经验的程序员有时也会碰到此问题，笔者就有一次，故与网友们"分享这次遭遇"。 让ORM为即将要持久的实体生成ID值(ORM的主键策略)，是典型的做法，例如有自增长(即便是DBMS来做)、UUID，Hibernate框架则更多。因此，不能手工为此实体赋上ID值。笔者设计主要实体时，通常用UUID作主键，很显然它是字符型的。但是，有时会发现form表单为其赋一个长度为0的字符串，看html代码: <input name="id" type="text" id="id" value=""/> 注意 value="" 如果是增加，则不需要在form表单中安置这么个控件，笔者通常将增加和修改实体在一个form表单中完成，笔者很喜欢用Spring MVC。这时id字段被Spring MVC包装到实体中就有值了(其值是长度为0的空字符串)。ORM保存时上面的异常就来了。解决的办法很多，笔者是为其实体做一个属性编辑器，在编辑器判断ID是否为空且长度是否为0，若是，则置入一个null。在保存前检查一下ID也是一种解决办法。 有时在一对一、一对多保存时，关联方也会存在这种情况，所以关键检查ID字段就可以了 http://howsun.blog.sohu.com/129035715.html
spring生成EntityManagerFactory的三种方式 1.LocalEntityManagerFactoryBean 只是简单环境中使用。它使用JPA PersistenceProvider自动检测机制( according to JPA’s Java SE bootstrapping ),并且大多数情况下,你只能定义一下persistence unit name 例如: 2.从JNDI获取EntityManagerFactory 这个选项是当你应用发布在javaee5的服务器中。你可以参阅自己应用服务器文档,如何发布一个自定义的JPA provider到你的应用服务器中。 例: <jee:jndi-lookup id=“myEmf” jndi-name=“persistence/myPersistenceUnit”/> 当javaee服务器启动时,会自动检测persistence units。实际上,是检测应用包中的META-INF/persistence.xml 文件和web.xml中的persistence-unit-ref,以及定义的environment naming。我理解就是JNDI的name。 一般应用情景是: 在META-INF/persistence.xml中 使用java:/ MySQLDS 获取容器发布的Datesource。 ...
JPA的persistence.xml文件 Posted on 2012-05-24 12:27 CN.programmer.Luxh 阅读(7217) 评论(0) 编辑 收藏 persistence.xml文件必须定义在classpath路径下的META-INF文件夹中。 我们看看基于Hibernate提供的一个比较完整的JPA2.0的persistence.xml文件。 persistence.xml: 复制代码 1 2 <persistence version=“2.0” xmlns=“http://java.sun.com/xml/ns/persistence" 3 xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance" 4 xsi:schemaLocation=“http://java.sun.com/xml/ns/persistence 5 http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"> 7 <!-必须要有name属性，不能为空 -> 8 9 <!-可选 -> 10 org.hibernate.ejb.HibernatePersistence 11 <!-可选 -> 12 java:/DefaultDS 13 <!-可选 -> 14 ormap.xml ...
jpa annotation, 注解 http://mzhj.iteye.com/blog/711685 @Embedded 你可以创建一个类被嵌套在实体类中，在这种情况下我们可以使用@Embedded注解。例如，在Hotel类中 可能会有一个Address。 Address是Hotel不可分割的一部分，没有ID, 并且不会被存储在分开的collection中。在这种情况下我们可以使用@Embedded注解 @Entity 标识这个pojo是一个jpa实体 Specifies that the class is an entity. This annotation is applied to the entity class. @Table (name= users ) //指定表名为users @Column @Column(name=“DESC”, nullable=false, length=512) 设置字段类型 通过@Column注解设置，包含的设置如下 .name: 字段名 .unique: 是否唯一 .nullable: 是否可以为空 .inserttable: 是否可以插入 .updateable: 是否可以更新 .columnDefinition: 定义建表时创建此列的DDL .secondaryTable: 从表名。如果此列不建在主表上 (默认建在主表) ，该属性定义该列所在从表的名字。 @Column(name = “user_code”, nullable = false, length=32)//设置属性userCode对应的字段为user_code，长度为32，非空 private String userCode; @Column(name = “user_wages”, nullable = true, precision=12, scale=2)//设置属性wages对应的字段为user_wages，12位数字可保留两位小数，可以为空 ...
JPA EntityManager的四个主要方法 ——persist,merge,refresh和remove public void persist(Object entity) persist 方法可以将实例转换为 managed( 托管 ) 状态。在调用 flush() 方法或提交事物后,实例将会被插入到数据库中。 对不同状态下的实例 A , persist 会产生以下操作 : 如果 A 是一个 new 状态的实体,它将会转为 managed 状态； 如果 A 是一个 managed 状态的实体,它的状态不会发生任何改变。但是系统仍会在数据库执行 INSERT 操作； 如果 A 是一个 removed( 删除 ) 状态的实体,它将会转换为受控状态； 如果 A 是一个 detached( 分离 ) 状态的实体,该方法会抛出 IllegalArgumentException 异常,具体异常根据不同的 JPA 实现有关。 public void merge(Object entity) merge 方法的主要作用是将用户对一个 detached 状态实体的修改进行归档,归档后将产生一个新的 managed 状态对象。 对不同状态下的实例 A , merge 会产生以下操作 : 如果 A 是一个 detached 状态的实体,该方法会将 A 的修改提交到数据库,并返回一个新的 managed 状态的实例 A2 ； ...
JPA 实体生命周期 JPA 实体生命周期分为4种状态，其实跟HIBERNATE的映射实体差不多。分为: 新建，受管 (托管) ，分离 (游离) ，删除。 新建: 此时的内存中已经创建了实体实例 ( 比如 NEW People() ) ，但是还没有同数据库或持久化上下文进行关联，所以目前它还不是一个标准的持久实体身份。所以对它的任何改变，都不会同步到数据库中。 受管: 此时实体已经在数据库中存在了持久化身份，并且同持久化上下文进行了关联，一般来说，在调用JPA的persist API后，实体实例已处于受管状态了。在修改实体之后，当事务提交，或显示调用flush()操作，实体状态会同步到数据库中。 分离: 还具有持久化身份，但是不在同持久化上下文关联。 删除: 同持久化上下文关联，但是客户已经打算从数据库销毁这一实体。 JPA的EntityManager也为我们准备好了API来完成对这些实体的操作: persist方法将实体变为受管状态，持久化到数据库。merge方法将当前的实体状态合并 (更新) 到当前持久化上下文中。remove方法直接从数据库里销毁实体 (删除) ，remove方法只是将数据库里的实体删除，并没有销毁内存里的实体对象，当事务提交或者调用flush方法，数据库里的实体才会被删除。 http://blog.163.com/oyhj_nicholas/blog/static/323592520107211295105
Maven构建之依赖传递 http://a123159521.iteye.com/blog/774322 博客分类: Maven mavenjunit项目管理配置管理Apache 如果断Maven的依赖构建必须每一个项目都指定,那配置是累死人了,比如A依赖了20个项目,B依赖A,那么还要添加20个项目,那就悲剧了,maven有依赖传递的功能。 Transitive Dependency (传递依赖) 你的项目依赖于A,A又依赖于B。你的项目是否要声明你依赖于B？ Maven的回答是它帮你自动管理这种依赖的传递,你不需要声明你依赖于B,由Maven来做。 [版本还是要自己指定的.] Dependency Scope (依赖范围) 因此,Maven考虑了6中可能的scope供选择: compile: 默认的scope。编译、测试、打包全都需要。compile参与依赖传递,就是说,你的项目A依赖于B(依赖scope是compile),项目C依赖于你的项目A,那么C也就依赖于B。 provided: 表示JDK或者容器会在Runtime时提供这些(jar),如上面说到的servlet api。provided的东西在编译和测试时会用到,不参与传递依赖。 runtime: 表示编译时不需要,但测试和运行时需要,最终打包时会包含进去。 test: 只用于测试阶段 (测试的编译和测试的运行) ,典型的就是junit的jar。 system: 和provided类似,但要求jar是你的系统里已有的,不会在repository里找,如rt.jar,tools.jar这些。 import: 简单的说,你的项目的pom可以继承另一个项目的pom,从而继承了父项目的依赖关系,但是因为之后single inheritance的限制,所以创造了import,使得你可以"导入"或者说"继承"任何一到多个项目的依赖关系。 依赖管理(dependencyManagement) 实际的项目中,你会有一大把的Maven模块,而且你往往发现这些模块有很多依赖是完全项目的,A模块有个对spring的依赖,B模块也有,它们的依赖配置一模一样,同样的groupId, artifactId, version,或者还有exclusions, classifer。细心的分会发现这是一种重复,重复就意味着潜在的问题,Maven提供的dependencyManagement就是用来消除这种重复的。 为了实现项目间的依赖,一般情况下,web项目依赖于app项目,而app项目很可能依赖于其他的app项目,比如我建了一个util项目,app依赖于util,那么webapp也需要依赖于util,但是我不配置webapp依赖util,验证一下,会不会自动加载依赖包. util项目的构建请参照前讲,接下来看maven配置: util配置; Java代码 收藏代码 <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns=“http://maven.apache.org/POM/4.0.0" xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance"> 4.0.0 demo ...
表的主键应当不具有任何业务含义 http://blog.sina.com.cn/s/blog_8020e4110101befz.html 表的主键应当不具有任何业务含义 (2012-12-17 15:10:36)转载▼ 标签: it 分类: DB/SQL 表的主键应当不具有任何业务含义 表通过主键来保证每条记录的唯一性，表的主键应当不具有任何业务含义，因为任何有业务含义的列都有改变的可能性。关系数据库学的最重要的一个理论就是: 不要给关键字赋予任何业务意义。假如关键字具有了业务意义，当用户决定改变业务含义，也许他们想要为关键字增加几位数字或把数字改为字母，那么就必须修改相关的关键字。一个表中的主关键字有可能被其他表作为外键。就算是一个简单的改变，譬如在客户号码上增加一位数字，也可能会造成极大的维护上的开销。 为了使表的主键不具有任何业务含义，一种解决方法是使用代理主键，例如为表定义一个不具有任何业务含义的ID字段 (也可以叫其他的名字) ，专门作为表的主键。 ——孙卫琴《精通Hibernate: Java对象持久化技术详解 本文来自CSDN博客，转载请标明出处: http://blog.csdn.net/jackie_lee/archive/2006/08/01/1007948.aspx ======================================= 昨天令狐因为处理动网论坛的数据库时，发现它是用帖子号来作为主键，由于无意中对它作了一些修改，导致帖子的关联变得混乱了。于是我们讨论了一下数据库表中主键的选择问题。因为对动网论坛的程序不熟，所以我也不知道它是怎么设计实现的，今天令狐把JavaEye上的一个关于这个方面的话题拿来讨论就好办了。 我起初也觉得用一个无意义的逻辑主键是一个好办法，至少说用一个字段就可以唯确定一条记录，使用上会很方便，速度应该也会快些。但是看了JavaEye那个帖里的讨论，以及在QQ群里的讨论后，我发现不完全是这样的。 其实这是两种不同的设计思路，谈不上用逻辑主键一定比用业务主键好。 用业务主键是传统的C/S应用开发的思路，包括我现在用的SAP里，也大量使用业务主键。但如果用O/R Mapping，则可能用逻辑主键好一些。 因 为对于传统C/S应用来说，以典型的两层结构看，前端处理的是一个数据表示的工作，后端处理的是一个数据持久化的工作。业务逻辑分散在两端，特别是在后 端。因为需要在后端通过Stored Procedure和View等来实现业务逻辑，应用直接与关系数据库打交道，所以数据的记录不但要求便于程序访问，对开发者来说，还要易读。也就是说需 要数据库的关系逻辑能够清晰地表达出业务逻辑来。主键采用业务主键是自然甚至是必须的。 而ORM应用恰恰相反。它需要一个最简单的 办法来标记一条唯一记录，但不需要有具体的意义，就像在OOP中，我们访问一个Object总是通过指针 (或相似的引用) ，但我们并不需要知道这个指针具 体的值是0x89ABCDEF还是0xFEDCBA98。逻辑主键就相当于一个指针，当别的关联表引用到这条记录时，用一个外键字段记录了这个逻辑主键， 就相当于那个Object中有一个属性记录了一个指向这个Object的指针。这时如果用业务主键-特别是复合业务主键-就是存心给自己打麻烦了。最 糟糕的情况就是当需要修改这个业务主键的值的时候，会导致所有的关联发生混乱-在传统C/S应用中，我们是用Trigger来解决这个问题，但是在 ORM中不可能这样做，否则那还要ORM干什么？ 当然，对于开发者来说，在ORM这样的情况下，用逻辑主键存在一个至关重要的问题 就在于数据的可读性将要变差。也就是说，除非通过OO的视角来看数据才是易于理解的。但如果直接进入后端看关系数据库，将变得困难。因此，基本上，逻辑主 键与ORM是相辅相成的，缺一不可，并且采用ORM的开发者要尽可能避免与后端的关系数据打交道，否则就会非常的痛苦。 正如令狐所作的总结: 一个是从OO角度看，一个是直接深入数据库内部看。 关于数据库表应该采用逻辑主键还是业务主键的讨论 ============================= 数据库主键不应该具有任何业务意义 关系数据库学的最重要的一个理论是: 不要给关键字赋予任何业余意义。假如关键字具有了业务意义，当用户决定业务含义，也许他们想要为关键字增加几位数字或者把数字改为字母，那么就必须修改相关的关键字。一个表中的主关键字有可能被其他表做为外键。就算是一个简单的改变，也可能会造成极大的维护上的开销。 为了使表的主键不具有任何业务意义，一种解决办法是使用代理主键，例如为表定义一个不具有任何业务含义的ID字段 (也可以叫其他名字) ，专门做为表的主键。 我回顾我以前设计的很多数据库，都在某些地方没有考虑周到，即使大部分的主键都没有业务意义，还是会有某些表的主键和业务联系起来。因为我一直认为，主键是用来保持唯一性的，之所以要有代理主键，是因为有一些记录的内容没办法保持唯一性。例如设计一个用户表，用户的名字有可能重复，这个人可能叫blue，那么人也可能叫blue。这样就需要一个ID来分清。 由于我之前的想法，导致我数据库设计上的一些错误。例如我曾经在一次数据库设计中使用一个ID来做为一个表的主键，该表是记录一些报表的。每个报表上都有一个ID，这个ID是具有业务意义的，是可以让客户输入，也可以自动生成的，但是客户说明这个ID是唯一的，是数字类型。因此由于它的唯一性，我在数据库中设计这个ID为数字类型的。但是到了后来客户要求使用文字类型的，例如原来的是"111111"，他要求可以写成"11111A"，“11111B”。这个时候由于这个ID做了很多表的外键，就会产生很多维护上面的麻烦。即使在数据库表之间做了级联更新和级联删除，修改数据类型还是很麻烦的事情。 这次RFID项目数据库设计我原来想使用RFID标签的ID做为产品的主键，因为RFID标签ID具有唯一性，使用它作为主键在查找的时候速度应该会快些。但是后来发现问题并不是这么简单。如果使用RFID标签ID做为主键，那么就具有了业务意义。当产品表和其他表关联，产品表的主键做为其他表的外键的时候，如果出现一些业务上的情况，例如RFID标签坏了，要更换，就会产生更改主键内容的问题了。 回顾一下，还是发现自己的基础不扎实。学习数据库的时候都不去上课。少年不努力，老大徒悲伤。 ==================================== 数据库中主键和外键的设计原则 主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。 必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。 主键: 关系数据库依赖于主键-它是数据库物理模式的基石。主键在物理层面上只有两个用途: 惟一地标识一行。 作为一个可以被外键有效引用的对象。 基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则: 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。 主键应该是单列的，以便提高连接和筛选操作的效率。 注: 使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是: 复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。 注: 这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。 ...
mybatis 动态 sql <update id="updateAuthorIfNecessary"> update Author <set> <if test="username != null">username=#{username},</if> <if test="password != null">password=#{password},</if> <if test="email != null">email=#{email},</if> <if test="bio != null">bio=#{bio}</if> </set> where id=#{id} </update> http://mybatis.github.io/mybatis-3/zh/dynamic-sql.html
Meson 一、什么是Meson Meson（The Meson Build System）是个项目构建系统，如Makefile，automake，CMake…。Meson是一个Python实现的开源项目，其思想是，开发人员花费在构建调试上的每一秒都是浪费，同样等待构建过程直到真正开始编译都是不值得的。 因此，Meson的设计目的是在用户友好的同时不损害性能，Meson提供客户语言（custom language）作为主要工具，用户可以使用它完成项目构建的描述。客户语言的设计目标是简单（simplicity）、清晰（clarity）、简洁（conciseness），其中很多灵感来源于Python语言。 Meson的另个一主要设计目的是为现代编程工具提供优秀的支持和最好的实现。这包括一些特性如：单元测试（unit testing）、代码覆盖率报告（code coverage reporting）、头文件预编译（precompiled headers）。用户不需要寻找三方宏指令（third party macros）或编写shell脚本来实现这些特性，Meson只要开箱即用（work out of the box）。 二、Meson有什么特点 对Linux，macOS，Windows，GCC，Clang，Visual Studio等提供多平台支持 支持的语言包括C，C ++，D，Fortran，Java，Rust 在非常易读且用户友好的非图灵完整DSL中构建定义 适用于许多操作系统和裸机的交叉编译 针对极快的完整和增量构建进行了优化，而不会牺牲正确性 内置的多平台依赖提供程序，可与发行版软件包一起使用 好玩！ ———————————————— 版权声明：本文为CSDN博主「espresso_yu」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/u010074726/article/details/108695256
Java写xml文件的编码问题 http://itindex.net/detail/49012-java-xml-%E6%96%87%E4%BB%B6 最近项目中需要生成xml格式的配置文件,用的是 javax.xml.transform.Transformer 类中提供的transform方法,在本地执行没问题,但是一旦把工程部署到Tomcat下运行,就会出现中文乱码的现象,纠结了许久,在大神的帮助下终于解决了。 有篇文章其实已经讲的很清楚了,链接如下: http://www.cnblogs.com/yunmou/archive/2013/02/19/2917646.html 但是按照他给的方法还是不行,问题就出在 OutputStreamWriter osw = new OutputStreamWriter(fos); // 注意。。。 这一行,作者虽然加了注意,但没说明怎么办,让我更加迷惑。 最后查了若干资料,发现确实是需要在这个地方进行注意。 最终代码如下: Source source = new DOMSource((Document) obj); // Create a new Transformer that performs a copy of the Source to the Result. TransformerFactory transFactory = TransformerFactory.newInstance(); Transformer transFormer = transFactory.newTransformer(); transFormer.setOutputProperty(OutputKeys.ENCODING, “UTF-8”); transFormer.setOutputProperty(OutputKeys.METHOD, “xml”); transFormer.setOutputProperty(OutputKeys.INDENT, “no”); OutputStreamWriter outputStreamWriter = new OutputStreamWriter( new FileOutputStream(path), “UTF-8”); Result xmlResult = new StreamResult(outputStreamWriter); // Transform the XML Source to a Result. ...
java 自定义异常, customized exception 编写自定义异常类的模式 编写自定义异常类实际上是继承一个API标准异常类,用新定义的异常处理信息覆盖原有信息的过程。常用的编写自定义异常类的模式如下: public class CustomException extends Exception { //或者继承任何标准异常类 public CustomException() {} //用来创建无参数对象 public CustomException(String message) { //用来创建指定参数对象 super(message); //调用超类构造器 } } 当然也可选用Throwable作为超类。其中无参数构造器为创建缺省参数对象提供了方便。第二个构造器将在创建这个异常对象时提供描述这个异常信息的字符串,通过调用超类构造器向上传递给超类,对超类中的toString()方法中返回的原有信息进行覆盖。 来讨论一个具体例子。假设程序中需要验证用户输入的表示年龄的数据必须是正整数值。我们可以按照以上模式编写这个自定义异常类如下: public class NegativeAgeException extends Exception { //或者: extends Throwable public NegativeAgeException() {} public NegativeAgeException(String message) { super(message); } } 下面是应用这个自定义异常类的例子: //完整程序存在本书配套资源目录为Ch11中名为NegativeAgeExceptionTest.java … try{ String ageString = JOptionPane.showInputDialog(“Enter your age: “); if (Integer.parseInt(ageString) < 0) throw new NegativeAgeException(“Please enter a positive age”); else JOptionPane.showMessageDialog(null, ageString, “Age”, 1); } catch(NegativeAgeException e){ ...
JPA EntityManager——persist,merge,refresh和remove public void persist(Object entity) persist 方法可以将实例转换为 managed( 托管 ) 状态。在调用 flush() 方法或提交事物后，实例将会被插入到数据库中。 对不同状态下的实例 A ， persist 会产生以下操作 : 如果 A 是一个 new 状态的实体，它将会转为 managed 状态； 如果 A 是一个 managed 状态的实体，它的状态不会发生任何改变。但是系统仍会在数据库执行 INSERT 操作； 如果 A 是一个 removed( 删除 ) 状态的实体，它将会转换为受控状态； 如果 A 是一个 detached( 分离 ) 状态的实体，该方法会抛出 IllegalArgumentException 异常，具体异常根据不同的 JPA 实现有关。 public void merge(Object entity) merge 方法的主要作用是将用户对一个 detached 状态实体的修改进行归档，归档后将产生一个新的 managed 状态对象。 对不同状态下的实例 A ， merge 会产生以下操作 : 如果 A 是一个 detached 状态的实体，该方法会将 A 的修改提交到数据库，并返回一个新的 managed 状态的实例 A2 ； ...
JPA (1) 、JPA介绍: JPA全称为Java Persistence API ,Java持久化API是Sun公司在Java EE 5规范中提出的Java持久化接口。JPA吸取了目前Java持久化技术的优点,旨在规范、简化Java对象的持久化工作。使用JPA持久化对象,并不是依赖于某一个ORM框架。 为什么要使用JAP? 在说为什么要使用JPA之前,我们有必要了解为什么要使用ORM技术。 ORM 是Object-Relation-Mapping,即对象关系影射技术,是对象持久化的核心。ORM是对JDBC的封装,从而解决了JDBC的各种存在问题: a) 繁琐的代码问题 用JDBC的API编程访问数据库,代码量较大,特别是访问字段较多的表的时候,代码显得繁琐、累赘,容易出错。例如: PreparedStatement pstmt=con.prepareStatment(“insert into account value(?,?,?,?,?,?,?,?,?)”); ORM则建立了Java对象与数据库对象之间的影射关系,程序员不需要编写复杂的SQL语句,直接操作Java对象即可,从而大大降低了代码量,也使程序员更加专注于业务逻辑的实现。 b) 数据库对象连接问题 关系数据对象之间,存在各种关系,包括1对1、1对多、多对1、多对多、级联等。在数据库对象更新的时候,采用JDBC编程,必须十分小心处理这些关系,以保证维持这些关系不会出现错误,而这个过程是一个很费时费力的过程。 ORM建立Java对象与数据库对象关系影射的同时,也自动根据数据库对象之间的关系创建Java对象的关系,并且提供了维持这些关系完整、有效的机制。 c) 系统架构问题 JDBC属于数据访问层,但是使用JDBC编程时,必须知道后台是用什么数据库、有哪些表、各个表有有哪些字段、各个字段的类型是什么、表与表之间什么关系、创建了什么索引等等与后台数据库相关的详细信息。 使用ORM技术,可以将数据库层完全隐蔽,呈献给程序员的只有Java的对象,程序员只需要根据业务逻辑的需要调用Java对象的Getter和 Setter方法,即可实现对后台数据库的操作,程序员不必知道后台采用什么数据库、有哪些表、有什么字段、表与表之间有什么关系。 d) 性能问题 采用JDBC编程,在很多时候存在效率低下的问题。 pstmt =conn.prepareStatement(“insert into user_info values(?,?)”); for (int i=0; i<1000; i++) { pstmt.setInt(1,i); pstmt.setString(2,“User”+i.toString()); pstmt.executeUpdate(); } 以上程序将向后台数据库发送1000次SQL语句执行请求,运行效率较低。 采用ORM技术,ORM框架将根据具体数据库操作需要,会自动延迟向后台数据库发送SQL请求,ORM也可以根据实际情况,将数据库访问操作合成,尽量减少不必要的数据库操作请求。 JPA是目前比较流行的一种ORM技术之一,所以他拥有ORM技术的各种特点,当然他还有自己的一些优势: 1 标准化 JPA 是 JCP 组织发布的 Java EE 标准之一,因此任何声称符合 JPA 标准的框架都遵循同样的架构,提供相同的访问 API,这保证了基于JPA开发的企业应用能够经过少量的修改就能够在不同的JPA框架下运行。 2 对容器级特性的支持 JPA 框架中支持大数据集、事务、并发等容器级事务,这使得 JPA 超越了简单持久化框架的局限,在企业应用发挥更大的作用。 3 简单易用,集成方便 ...
‘在web.xml中classpath和classpath*的区别’ 写spring的代码到现在,一直都很习惯性的拷贝web.xml中的内容,没怎么在意里面的内容,最近认真研究了下,很多东西都不是很理解,特别是classpath和classpath*的区别,研究了许久才搞明白,记录下备忘。 classpath 和 classpath* 区别: classpath: 只会到你指定的class路径中查找找文件; classpath*: 不仅包含class路径,还包括jar文件中(class路径)进行查找. 举个简单的例子,在我的web.xml中是这么定义的: classpath*:META-INF/spring/application-context.xml 那么在META-INF/spring这个文件夹底下的所有application-context.xml都会被加载到上下文中,这些包括META-INF/spring文件夹底下的 application-context.xml,META-INF/spring的子文件夹的application-context.xml以及jar中的application-context.xml。 如果我在web.xml中定义的是: classpath:META-INF/spring/application-context.xml 那么只有META-INF/spring底下的application-context.xml会被加载到上下文中。
DB 事务 事务(Transaction): 是并发控制的单元，是用户定义的一个操作序列。这些操作要么都做，要么都不做，是一个不可分割的工作单位。通过事务，sql server 能将逻辑相关的一组操作绑定在一起，以便服务器 保持数据的完整性。事务通常是以begin transaction开始，以commit或rollback结束。Commint表示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据的更新写回到磁盘上的物理数据库中去，事务正常结束。Rollback表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续进行，系统将事务中对数据库的所有已完成的操作全部撤消，滚回到事务开始的状态。 1、事务的特性 (ACID): 原一隔持 原子性 (Atomic) : 即事务是不可分割的最小工作单元，事务内的操作，要么全部执行，要么全部不执行。 一致性 (Consistency) : 事务在完成时，必须是所有的数据都保持一致状态。 在事务执行前数据库的数据处于正确的状态，而事务执行完成后数据库的数据还是处于正确的状态，即数据完整性约束没有被破坏；如银行转帐，A转帐给B，必须保证A的钱一定转给B，一定不会出现A的钱转了但B没收到，否则数据库的数据就处于不一致 (不正确) 的状态。 隔离性 (Isolation) : 一个事务的执行不能被其他事务所影响。 并发事务执行之间无影响，在一个事务内部的操作对其他事务是不产生影响，这需要事务隔离级别来指定隔离性； 事务必须是互相隔离的，防止并发读写同一个数据的情况发生 。 持久性 (Durable) : 一个事务一旦提交，事物的操作便永久性的保存在DB中。即使此时再执行回滚操作也不能撤消所做的更改。 事务类型 数据库事务类型有本地事务和分布式事务: 本地事务: 就是普通事务，能保证单台数据库上的操作的ACID，被限定在一台数据库上； 分布式事务: 涉及两个或多个数据库源的事务，即跨越多台同类或异类数据库的事务 (由每台数据库的本地事务组成的) ，分布式事务旨在保证这些本地事务的所有操作的ACID，使事务可以跨越多台数据库； Java事务类型有JDBC事务和JTA事务: JDBC事务: 就是数据库事务类型中的本地事务，通过Connection对象的控制来管理事务； JTA事务: JTA指Java事务API(Java Transaction API)，是Java EE数据库事务规范， JTA只提供了事务管理接口，由应用程序服务器厂商 (如WebSphere Application Server) 提供实现，JTA事务比JDBC更强大，支持分布式事务。 Java EE事务类型有本地事务和全局事务: 本地事务: 使用JDBC编程实现事务； 全局事务: 由应用程序服务器提供，使用JTA事务； 按是否通过编程实现事务有声明式事务和编程式事务； 声明式事务: 通过注解或XML配置文件指定事务信息； 编程式事务: 通过编写代码实现事务。 隐式事务: 当连接以隐式事务模式进行操作时，sql server数据库引擎实例将在提交或回滚当前事务后自动启动新事务。无须描述事物的开始，只需提交或回滚每个事务。但每个事务仍以commit或rollback显式结束。连接将隐性事务模式设置为打开之后，当数据库引擎实例首次执行下列任何语句时，都会自动启动一个隐式事务: alter table，insert，create，open ，delete，revoke ，drop，select， fetch ，truncate table，grant，update在发出commit或rollback语句之前，该事务将一直保持有效。在第一个事务被提交或回滚之后，下次当连接执行以上任何语句时，数据库引擎实例都将自动启动一个新事务。该实例将不断地生成隐性事务链，直到隐性事务模式关闭为止。 ...