最近的项目ORM框架使用的是Hibernate,数据库使用PostgreSQL,俩个都是开源的高大上产品,Hibernate就不用说啦,主流的ORM框架,PostgreSQL第一次接触,其中包含Json数据类型的字段,这种类型意味着它能够像非关系型数据库那样存储数据,数据扩展性很是好,这也是项目使用它的主要缘由之一。 在Hibernate和PostgreSQL的结合过程当中遇到了针对Json数据类型,Hibernate并无Json这种数据映射字段,想了下是否是版本的问题,也许高版本Hibernate已经支持这种类型啦,下载最新版本Hibernate看下啦,仍然不支持,这点不是很明白,PostgreSQL已经支持Json这么长时间啦,并且如今MySQL最新版本也已经支持Json数据格式啦,身为主流ORM框架怎么到如今尚未提供这种数据类型,无论啦,也许人家提供了其余想法,大公司的想法是咱们这些吊私没法猜想的,做为咱们就是寻找解决方案就能够啦,毕竟人家已经开源了嘛。
毕竟这俩框架已经诞生这么长时间啦,这种常见问题确定有了很好的解决方案,果真在stackoverflow找到了一些解决方案,这里只作整理说明,可以解决当前项目中的问题,不作深刻探究。前端
一、在数据库端处理java
CREATE OR REPLACE FUNCTION json_intext(text) RETURNS json AS $$ SELECT json_in($1::cstring);
$$ LANGUAGE SQL IMMUTABLE;
上面的函数是将指定text类型数据转换成json数据个数sql
二、在Hibernate端处理数据库
import org.hibernate.HibernateException; import org.hibernate.engine.spi.SessionImplementor; import org.hibernate.usertype.UserType; import java.io.Serializable; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Types; /** * @author timfulmer */ public class StringJsonUserType implements UserType { /** * Return the SQL type codes for the columns mapped by this type. The * codes are defined on <tt>java.sql.Types</tt>. * * @return int[] the typecodes * @see java.sql.Types */ @Override public int[] sqlTypes() { return new int[] { Types.JAVA_OBJECT}; } /** * The class returned by <tt>nullSafeGet()</tt>. * * @return Class */ @Override public Class returnedClass() { return String.class; } /** * Compare two instances of the class mapped by this type for persistence "equality". * Equality of the persistent state. * * @param x * @param y * @return boolean */ @Override public boolean equals(Object x, Object y) throws HibernateException { if( x== null){ return y== null; } return x.equals( y); } /** * Get a hashcode for the instance, consistent with persistence "equality" */ @Override public int hashCode(Object x) throws HibernateException { return x.hashCode(); } /** * Retrieve an instance of the mapped class from a JDBC resultset. Implementors * should handle possibility of null values. * * @param rs a JDBC result set * @param names the column names * @param session * @param owner the containing entity @return Object * @throws org.hibernate.HibernateException * * @throws java.sql.SQLException */ @Override public Object nullSafeGet(ResultSet rs, String[] names, SessionImplementor session, Object owner) throws HibernateException, SQLException { if(rs.getString(names[0]) == null){ return null; } return rs.getString(names[0]); } /** * Write an instance of the mapped class to a prepared statement. Implementors * should handle possibility of null values. A multi-column type should be written * to parameters starting from <tt>index</tt>. * * @param st a JDBC prepared statement * @param value the object to write * @param index statement parameter index * @param session * @throws org.hibernate.HibernateException * * @throws java.sql.SQLException */ @Override public void nullSafeSet(PreparedStatement st, Object value, int index, SessionImplementor session) throws HibernateException, SQLException { if (value == null) { st.setNull(index, Types.OTHER); return; } st.setObject(index, value, Types.OTHER); } /** * Return a deep copy of the persistent state, stopping at entities and at * collections. It is not necessary to copy immutable objects, or null * values, in which case it is safe to simply return the argument. * * @param value the object to be cloned, which may be null * @return Object a copy */ @Override public Object deepCopy(Object value) throws HibernateException { return value; } /** * Are objects of this type mutable? * * @return boolean */ @Override public boolean isMutable() { return true; } /** * Transform the object into its cacheable representation. At the very least this * method should perform a deep copy if the type is mutable. That may not be enough * for some implementations, however; for example, associations must be cached as * identifier values. (optional operation) * * @param value the object to be cached * @return a cachable representation of the object * @throws org.hibernate.HibernateException * */ @Override public Serializable disassemble(Object value) throws HibernateException { return (String)this.deepCopy( value); } /** * Reconstruct an object from the cacheable representation. At the very least this * method should perform a deep copy if the type is mutable. (optional operation) * * @param cached the object to be cached * @param owner the owner of the cached object * @return a reconstructed object from the cachable representation * @throws org.hibernate.HibernateException * */ @Override public Object assemble(Serializable cached, Object owner) throws HibernateException { return this.deepCopy( cached); } /** * During merge, replace the existing (target) value in the entity we are merging to * with a new (original) value from the detached entity we are merging. For immutable * objects, or null values, it is safe to simply return the first parameter. For * mutable objects, it is safe to return a copy of the first parameter. For objects * with component values, it might make sense to recursively replace component values. * * @param original the value from the detached entity being merged * @param target the value in the managed entity * @return the value to be merged */ @Override public Object replace(Object original, Object target, Object owner) throws HibernateException { return original; } }
上面的类实现Hibernate的UserType接口,这样就能够定义Hibernate端的数据类型,这样将对应数据库中Json字段的JavaBean中的数据字段定义成String类型,这样javaBean中指定字段就能和数据库中json造成映射json
例如sass
<property name="atts" type="com.quangao.hibernate.StringJsonUserType"> <column name="atts" /> </property>
这样session.save(entity);的时候就能够将json字段成功保存markdown
上述俩种方法,第一种虽能实现,但需在数据中频繁转换,自己简单的保存修改变得很麻烦,明显不切符合解耦概念,这是将前端的事情强加给数据库来处理的,并且不符合Hibernate存在的缘由,二第二种方法很好的实现了所谓的映射关系,数据库端不须要作任何多余的事情。因此我选择了第二种方案。session
版权声明:本文为博主原创文章,未经博主容许不得转载。app