XSql--Orm数据库框架,轻量,自动升级,自动降级的数据库框架。

XSql 自动 升级/降级 的数据库框架

还在为数据库各种升级要写一堆代码而头疼吗,版本迭代,数据库维护难受的要死,每次增加字段,删除字段都要自己手动写代码处理?
那么你看到这篇文章后这些烦恼都不是问题!!!

故事:鄙人写项目时用了目前网上最流行的Orm数据库框架。先简单介绍一下greendao和ormlite。 greendao: 性能很强大,读写数据快,代码自动生成,确实好用,(学习成本可能高一点,比较难理解)。 ormlite: 性能可能要差一点,但是简单,入手很快。 缺点: 1、greendao确实好,但是升级数据库的代码还要用户自己实现,否则默认是删除所有的表,并重新创建,用户的数据很容易丢失。 2、ormlite也不错,需要用户集成OrmliteSQLOpenHelper并且自己写Dao类操作数据库,很麻烦。而且数据库升级也是要用户自己实现。 思来想去,网上就没有一个框架可以自动升级数据库吗,可以满足大部分情况的数据库升级的框架,搜了一大堆,然而并没什么卵用,没有开源的。所以查了许多资料看了许多框架的源码,搞出了这个性能还行,又可以**自动升级的数据库框架**。

秉承着开源的精神,将次框架开源,希望有兴趣的开发者共同完善优化此框架!

下面介绍一下次框架:
传送门:https://github.com/pichsy/xsql

XSql 自动 升级/降级 的数据库框架

1、项目介绍

  • 最新版本 : new 1.3
  • 这是一个Sqlite数据库框架,基于SqliteDatabseOpenHelper.
  • 这是一个面对对象的数据库框架,使用起来非常简单,易上手。
  • 增删改查,分页查询,简单方便。
  • 自动升级数据库,无需开发者关心,增加删除字段,随心所欲。
  • 性能强悍,支持大批量数据的并发,支持事务。
新版本已传至mavenCentral仓库,引用起来比老版本舒服一点
老版本: v1.1.3文档传送门

2、快速接入(两种方式任选其一)

2.1、直接导包 (推荐使用这种)

使用module级别的build.gradle导包

dependencies {
    implementation 'com.github.pichsy:xsql:1.3'
    annotationProcessor 'com.github.pichsy:xsql-processor:1.3'
}

注意:annotationProcessor 必须加上,注解处理器。

2.2、使用脚本导入

project级别的build.gradle中添加:

 dependencies {
     classpath 'com.github.pichsy:xsql-plugin:1.3'
 }

module级别的build.gradle <顶部> 中添加:

apply plugin: 'xsql-plugin'

即可,同步一下项目,即可使用xsql框架了。

3、如何使用?

3.1、使用注解

使用 @SqlTable(“xxxTableName”) 注解一个表名
使用 @SqlField(“xxxColumnName”) 注解一个字段
使用 @SqlGeneratedId 注解一个字段标志为自增长型,字段类型为long或int
使用 @SqlUnique 注解一个字段,标志字段对应存储内容唯一性
不添加@SqlField(“xxxColumnName”) 注解的字段,不添加到数据库

例如:

@SqlTable("tb_user")
public class User {
	
	// id自增长
	@SqlGeneratedId
	@SqlField("_id")
	long id;
	
	// 名字唯一
	@SqlUnique
	@SqlField("tb_name")
	String name;
	
	// 正常注解
	@SqlField("bt_age")
	String age;
	
	// 不注解字段不写入数据库
	String other
}
3.2、获取BaseDao

简单一行代码获取BaseDao

    private IBaseDao<User> mBaseDao;
    // 也可以使用BaseDao接收,(好处)多了几个方法。
    // private BaseDao<User> mBaseDao;  
   
    private void initSql() {
        //可以使用默认的数据库名字和版本(数据库名字为包名('.'被'-'替换).db, 版本默认为1)
        mBaseDao = XSql.getDBManager(this).getBaseDao(SqlModel.class);
    }  
    
    // 当然也可以自定义
    private void initSql() {
        // 使用DBConfig来自定义数据库的名字和版本
        DBConfig dbConfig = new DBConfig().setDBName("my_app.db");
        mBaseDao = XSql.getDBManager(this,dbConfig).getBaseDao(SqlModel.class);
    }  
3.3、数据库的增、删、改、查 ,分页查询操作

增删改查提供了非常简单的api,一行代码,轻松搞定。当然也提供了复杂的查询——WhereBuilder 来创建查询条件,后面有详细介绍。

3.3.1 增----插入数据

  User user = new User();
  user.setName("小李子");
  user.setAge(18);
  mBaseDao.insert(user);

3.3.2 删----删除数据

  mBaseDao.delete(user);

3.3.3 改----修改数据

  mBaseDao.update(user);

3.3.4 查----查询数据

 List<User> userList = mBaseDao.queryAll();

3.3.5 查----条件查询数据

WhereBuilder wb = new WhereBuilder().eq("name", "张三");
List<User> userList = mBaseDao.query(wb);

3.3.6 查----条件分页排序查询数据

int page = 0; // page: 页数是从0页开始
int size = 5; // size: 最小值是1
WhereBuilder wb = new WhereBuilder()
 		 .startWith("name","张")
 		 .page(page, size)
 		 .orderByDesc("_id");
List<User> userList = mBaseDao.query(wb);
3.4、数据库WhereBuilder创建条件,进行删除和查询
  • 注:(不支持修改,原因:修改传入修改后的对象即可,用不到条件)

3.4.1 使用

 WhereBuilder wb = new WhereBuilder().eq(XSqlProperties.User.age, 19);
 mBaseDao.query(wb);
 // 或者
 mBaseDao.delete(wb);

注释:XSqlProperties.User.age,这个是哪里来的呢?
注解处理器自动生成的类,此类为用户创建的实体字段名和表中的字段的映射,为了方便调用者使用

当然用户也可以不使用此类,直接使用 @SqlField 注解上的字段也行

 例:
 WhereBuilder wb = new WhereBuilder().eq("tb_age", 19);
 mBaseDao.query(wb);
 // 或者
 mBaseDao.delete(wb);

3.4.2 分页查询

 // 普通用法 ,单纯的分页
 int page = 0; // page: 页数是从0页开始
 int size = 5; // size: 最小值是1
 WhereBuilder wb = new WhereBuilder().page(page, size);
 mBaseDao.query(wb);	
 // 高级用法,条件查询+分页,page()方法必须放在最后。
  WhereBuilder wb = new WhereBuilder()
 		 .startWith("name","张").page(page, size);
 mBaseDao.query(wb);
 
 // 高级用法,条件分页+排序。
 WhereBuilder wb = new WhereBuilder()
   		 .page(page, size). orderByDesc("_id");
 mBaseDao.query(wb);
 

3.4.3 分页查询

 // 普通用法 ,单纯的分页
 int page = 0; // page: 页数是从0页开始
 int size = 5; // size: 最小值是1
 WhereBuilder wb = new WhereBuilder().page(page, size);
 mBaseDao.query(wb);	
 // 高级用法,条件查询+分页,page()方法必须放在最后。
  WhereBuilder wb = new WhereBuilder()
 		 .startWith("name","张").page(page, size);
 mBaseDao.query(wb);
 
 // 高级用法,条件分页+排序。
 WhereBuilder wb = new WhereBuilder()
   		 .page(page, size).orderByDesc("_id");
 mBaseDao.query(wb);
 

3.4.4 WhereBuilder方法介绍

*注:此字段:为传入的字段(column),此值:为传入的值(value)

方法    说明     
eq(String,obj)相等 ,匹配数据库中此字段与此值相等的数据。
notEq(String,obj)不相等 ,匹配数据库中此字段与此值不相等的数据。
and()连接下一个条件,同时满足
or()连接下一个条件,满足其一即可
gt(obj,obj)> 大于,数据库中此字段 > 此值的数据
lt(obj,obj)< 小于,数据库中此字段 < 此值的数据
ge(obj,obj)>= 大于等于,数据库中此字段 >= 此值的数据
le(obj,obj)<= 小于等于,数据库中此字段 <= 此值的数据
like(String,String)模糊查询,数据库中此字段 包含 此值的数据
notLike(String,String)模糊查询,数据库中此字段 不包含 此值的数据
startWith(String,String)模糊查询,数据库中此字段 以 此值 开头 的数据
endWith(String,String)模糊查询,数据库中此字段 以 此值 结尾 的数据
between(String,obj,obj)在两个数之间,数据库中此字段 在 值1 和 值2 之间 的数据
page(int,int)分页查询
orderByDesc(String)倒序,查询的数据以此字段 倒序排序(从大到小排序)
orderByAsc(String)正序,查询的数据以此字段 正序排序(从小到大排序)

四、版本升级说明

Version: 1.1.3
  • SqlProperties(注解自动生成的类)改为XSqlProperties。包名也变了,更新时请注意。见3.4.1
  • 增加WhereBuilder分页查询写法。
  • WhereBuilder wb = new WhereBuilder().page(page, size);
  • page方法再有条件查询或排序查询时:需写在条件查询之后,排序查询之前。详见3.4.3
Version: 1.1.2
  • 增加WhereBuilder可以直接排序的写法。
  • new WhereBuilder().orderByDesc("name")
  • 注:以前的写法为 new WhereBuilder().eq("1",1).orderByDesc("name"),此法不合理故修之
Version: 1.1.1
  • 修复bug并支持float类型
Version: 1.1.0
  • 使用说明见上文。
  • 版本升级内容:
    1. 自动升级数据库。(变动最大…,详见:五、数据库自动升级说明)
    2. 优化了一些增删改查,更安全。
    3. 新增了api,XSql类。
    4. 修改了旧的一些api,DBManager的Api.
    5. 增加了一些方法。
Version: 1.0.4
  • api相比 1.1.0 有所不同。
  • 变化1:
private IBaseDao<User> mBaseDao;
 
   private void initSql() {
       // 此处调用api变化
       mBaseDao = DBManager.getInstance(this).getBaseDao(User.class);
   }  

五、数据库自动升级说明

  • 数据库自动升级:
  • 支持升级,降级。
  • 升降级支持:
  • 新增字段,不会删除原本有的数据。
  • 删除字段,会删除删掉字段的数据,其他数据会保留。
  • 修改字段,会丢失修改的那个字段的数据(相当于,新增了一个字段 + 删除了一个字段)
  • 注意:升级数据库时:在没有删除某一(或多)个字段的情况下,不支持原有的字段上添加约束或者删除约束,即使在 原有字段上添加了约束(@SqlUnique注解)也不会生效。但是 新增的字段 上可以增加约束。
  • 注意:升级数据库时:在删除某一(或多)个字段的时候,可以删除另个一(或多)个字段的@SqlUnique注解。原因:删除字段时需要重新创建新的数据库,并且将原来的数据备份,并拷贝到新数据库中,这样符合sqlite数据操作数据原里,不会产生数据冲突。
  • 注意:升级数据库时:在删除某一(或多)个字段的时候,强行给原有字段添加约束(如:@SqlUnique注解)会导致程序崩溃,原因:数据库原有的数据不一定是唯一的(属于危险操作)。
  • 简单点说:在有删除某些字段的情况下,支持删除原有字段的约束,不支持原有字段增加约束。
  • 数据库升级是自动升级,可以不用修改verion。只需要增加或删除字段就行
  • 注:这里的约束一般指 @SqlUnique注解。没有**@SqlField(“xxx”)**注解的字段,可随便改,不会影响数据库。
  • 当然最重要的,开发者要保持良好的习惯,尽量不要经常做修改字段,删除字段这些危险的操作。
  • 此框架为了快速开发而建,无需关心数据库升级和创建的问题。随心所欲的添加字段,删除字段。(约束增加与删除,仔细看上面的三个“注意”)

结束语

  • 感谢广大的开源开发者。
  • 如此 帅气 的你,给我一颗 小小的 Star 吧。
  • 项目正在进一步维护,增加更多的功能。
  • 感谢许多开源框架的支持,greendao,ream,butterkinfe等。
  • 有问题的童鞋邮箱@我 sywubo789@163.com

看到这里,老铁赶紧去试试吧,简单的不要要的。就是这么爽。记得Star!

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
ef-orm A Simple OR-Mapping framework on multiple databases. 使用手册(中文)http://geequery.github.io/ef-orm/manual/EF-ORM-user-guide.docx  使用示例工程 https://github.com/GeeQuery/ef-orm/tree/master/orm-tutorial EF-ORM是一个轻量,便捷的Java ORM框架。并且具备若干企业级的应用特性,如分库分表、JTA事务等。 代码生成插件for eclipse(请在eclipse中Help/Install new software后输入地址并安装)http://geequery.github.io/plugins/1.3.x/特点一 EF的设计的一个主要目的是提高开发效率,减少编码工作,让开发者“零配置”“少编码”的操作数据库大部分功能。 例如:数据库查询条件的传入问题是所有ORM框架都不能回避的一个问题,所以我经常在想——既然我们可以用向DAO传入一个Entity来实现插入操作,为什么就不能用同样的方法来描述一个不以主键为条件的update/select/delete操作?为什么DAO的接口参数老是变来变去?为什么很多应用中,自行设计开发类来描述各种业务查询条件才能传入DAO?为什么我们不能在数据访问层上花费更少的时间和精力?   JPA1.0和早期的H框架,其思想是将关系型数据库抽象为对象池,这极大的限制了本来非常灵活的SQL语句的发挥空间。而本质上,当我们调用某H框架的session.get、session.load、session.delete时,我们是想传递一个以对象形式表达的数据库操作请求。只不过某H框架要求(并且限制)我们将其视作纯粹的“单个”对象而已。JPA 2.0为了弥补JPA1.0的不足,才将这种Query的思想引入为框架中的另一套查询体系——Criteria API。事实上针对单个对象的get/load/persist/save/update/merge/saveOrUpdate API和Criteria API本来就为一体,只不过是历史的原因被人为割裂成为两套数据库操作API罢了。   因此,对于关系型数据库而言——Entity和Query是一体两面的事物,所谓Query,可以包含各种复杂的查询条件,甚至可以作为一个完整的SQL操作请求的描述。为此,EF彻底将Entity和Query绑在了一起。这种思想,使得—— 开发人员需要编写的类更少。开发人员无需编写其他类来描述复杂的SQL查询条件。也无需编写代码将这些查询条件转换为SQL/HQL/JPQL。DAO层也不会有老要改来改去的接口和API,几乎可以做到零编码。 对单个对象进行CRUD的操作API现在和Criteria API合并在一起。Session对象可以直接提供原本要Criteria API才能提供实现的功能。API大大简化。 IQueryableEntity允许你将一个实体直接变化为一个查询(Query),在很多时候可以用来完成复杂条件下的数据查询。比如 ‘in (?,?,?)’, ‘Between 1 and 10’之类的条件。 xxQL有着拼装语句可读性差、编译器无法检查、变更维护困难等问题,但是却广受开发人员欢迎。这多少有历史原因,也有Criteria API设计上过于复杂的因素。两者一方是极端灵活但维护困难,一方是严谨强大而学习和编写繁琐,两边都是极端。事实上JPA的几种数据查询方式存在青黄不接的问题。选择查询语言xxQL,项目面临后续维护困难,跨数据库移植性差;选择Criteria API,代码臃肿,操作繁琐,很多人望而却步。EF的设计思想是使人早日摆脱拼装SQL/HQL/JPQL的困扰,而是用(更精简易用的)Criteria API来操作数据库。 基于轻量级Criteria API的操作方式,使得对数据库的变更和重构变得非常轻松,解决了SQL语句多对软件维护和移植造成产生的不利影响。 阅读推荐:第3、4章 特点二,将SQL的使用发挥到极致,解决SQL拼凑问题、数据库移植问题 大部分OLTP应用系统到最后都不免要使用SQL/JPQL,然而没有一个很好的方法解决SQL在多种数据库下兼容性的问题。 EF-ORM中采用了独特的SQL解析和改写技术,能够主动检查并确保SQL语句或者SQL片段在各个数据库上的兼容性。 EF中除了Criteria API以外,可以直接使用“SQL语句”或者“SQL片段”。但是这些SQL语句并不是直接传送给JDBC驱动的,而是 有着一个数据库方言层,经过方言层处理的SQL语句,就具备了在当前数据库上正确操作的能力。这相当于提供了一种能跨数据库操作的SQL语言。(E-SQL) E-SQL不但解决了异构数据库的语法问题、函数问题、特殊的写法问题,还解决了动态SQL问题、绑定变量扩展等特性。 对于各种常用SQL函数和运算符,都可以自动转换为当前数据库支持的方言来操作。其函数支持也要多于HQL支持的函数。 阅读推荐:第7、8章 特点三,可能是业界最快的ORM框架. 得益于ASM的动态代码生成技术,部分耗时操作通过动态代码固化为硬编码实现,EF-ORM的大部分操作性能要超过已知的其他框架。 实际性能测试表明,EF的大部分操作都要快于Hiberante和MyBatis, 部分操作速度甚至数十倍于上述框架。 EF在极限插入模式下,甚至刷新了每秒10万条写入的记录。远远超过了其他框架。 一个初步的性能测试:测试代码:http://geequery.github.io/ef-orm/manual/performance-test.rar 测试报告:http://geequery.github.io/ef-orm/manual/performance-compare.docx 阅读推荐:第9、17章 特点四,分库分表 开发过程中参照了Hibernate Shards、Alibaba TDDL、Cobar等框架,也是基于词法分析器来提取SQL参数,并计算路由。 能支持分库维度含糊等场景下的分库分表。以及包括多库多表下的 order by , distinct, group by, having等操作。 阅读推荐:第10章 特点五,常用DDL操作的封装 从数据库元数据访问,到建表,创建约束,创建sequence等各种DDL操作进行了封装,用户无需编写各种SQL,可以直接通过API操作数据库结构。 尤其是ALTER TABLE等修改数据库的语句,各种不同的RDBMS都有较大语法差异。特点六、解决各种跨RDBMS的移植问题 1、DML操作、自增值处理与返回、查询这些不同数据库操作差异很大的东西,都了统一的封装。 2、DDL操作、建表、删表、trunacte,Sequence创建和TABLE模拟Sequence等,都做了支持。 3、对SQL语法操作和函数的改写与支持。其他特性轻量框架对应用环境、连接池、 是否为J2EE应用等没有特殊要求。可以和EJB集成,也可与Spring集成,也可以单独使用。整个框架只有两个JAR包,模块和功能都较为轻量。依赖少 整个框架只有三个jar库。间接依赖仅有commons-lang, slf4j等7个通用库,作为一个ORM框架,对第三方依赖极小。简单直接的API 框架的API设计直接面向数据库操作,不绕弯子,开发者只需要数据库基本知识,不必学习大量新的操作概念即可使用API完成各种DDL/DML操作。 最大限度利用编译器减少编码错误的可能性 API设计和元数据模型(meta-model)的使用,使得常规的数据库查询都可以直接通过Criteria API来完成,无需使用任何JPQL/HQL/SQL。可以让避免用户犯一些语法、拼写等错误。JPA2规范兼容 使用JPA 2.0规范的标准注解方式来定义和操作对象。(但整个ORM不是完整的JPA兼容实现)更高的性能 依赖于ASM等静态字节码技术而不是CGlib,使得改善了代理性能;依赖于动态反射框架,内部数据处理上的开销几乎可以忽略。操作性能接近JDBC水平。对比某H开头的框架,在写入操作上大约领先30%,在大量数据读取上领先50%以上。更多的性能调优手段 debug模式下提供了大量性能日志,帮您分析性能瓶颈所在。同时每个查询都可以针对batch、fetchSize、maxResult、缓存、级联操作类型等进行调整和开关,可以将性能调到最优。可在主流数据库之间任意切换 支持Oracle、MySQL、Postgres、MSSQL、GBase、SQLite、HSQL、Derby等数据库。除了API方式下的操作能兼容各个数据库之外,就连SQL的本地化查询也能使之兼容。JMX动态调节 可以用JMX查看框架运行统计。框架的debug开关和其他参数都可以使用JMX动态调整。动态表支持 表结构元数据的API也向用户开放,同时支持在使用过程中,灵活调整映射关系,因此用户可以用API动态的创建表结构的模型,从而实现各种动态类型和表的映射(例如POJO中包含一个Map,用于映射各种动态扩展的字段)企业级特性支持 SQL分析,性能统计,分库分表,Oracle RAC支持,读写分离支持 标签:eform
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值