Dataway 4.1.4 发布,无需开发配置接口,新增支持 Oracle/多数据源

Dataway介绍

avatar

Dataway 是基于 DataQL 服务聚合能力,为应用提供的一个接口配置工具。使得使用者无需开发任何代码就配置一个满足需求的接口。 整个接口配置、测试、冒烟、发布。一站式都通过 Dataway 提供的 UI 界面完成。UI 会以 Jar 包方式提供并集成到应用中并和应用共享同一个 http 端口,应用无需单独为 Dataway 开辟新的管理端口。

这种内嵌集成方式模式的优点是,可以使得大部分老项目都可以在无侵入的情况下直接应用 Dataway。进而改进老项目的迭代效率,大大减少企业项目研发成本。

Dataway 工具化的提供 DataQL 配置能力。这种研发模式的变革使得,相当多的需求开发场景只需要配置即可完成交付。 从而避免了从数据存取到前端接口之间的一系列开发任务,例如:Mapper、BO、VO、DO、DAO、Service、Controller 统统不在需要。

Hasor v4.1.4 (2020-04-30)

新增

  • 接口可以跨域访问。

  • Dataway 增加 CompilerSpiListener 扩展点,可以自定义 DataQL 编译过程。

  • Dataway 增加 PreExecuteChainSpi 扩展点,可以在 DataQL 执行之前进行干预。配合 ResultProcessChainSpi 可以实现缓存和权限。

  • Dataway 增加 ResultProcessChainSpi 扩展点,可以对DataQL执行的结果进行二次处理。

  • hasor-spring 做整合的时,Hasor-web可以工作在 Filter模式下也可以工作在 SpringWebMVC 拦截器模式下

  • Dataway 新增 DatawayService 界面配置的接口可以在本地应用上用代码发起调用了。

  • issue Dataway 支持配置多个数据源。但一个 DataQL 查询中目前依然只能使用一种数据源。

  • issue Dataway 新增 Oracle 的支持。

  • 新增 FRAGMENT_SQL_COLUMN_CASE 选项,可以决定 SQL 执行器的返回结果 key 策略,是全部大写还是全部小写或者满足驼峰。

  • 新增 mapKeyToLowerCase、mapKeyToUpperCase、mapKeyToHumpCase 三个函数,对 Map 的 Key 做转换

优化

  • issue 改进 Dataway 在处理 GET 请求时,多个同名参数获取的问题。之前只能拿到数组形态,在于 POST 模式进行对比的时容易产生奇异造成认为是 Bug 的假象。

  • issue hasor-dataql-fx 项目中 ognl 内嵌到 jar包中,减少两个外部依赖 jar。

  • SpiInterceptor 机制有些说不清,改为 SpiJudge(仲裁机制:SPI 仲裁:当同一个 SPI bind 了多个监听器时,仲裁可以决定哪些 SPI 会被调用)

  • hasor-web 支持路径中出现多个连续 / ,例如: http://127.0.0.1:8080/app/////interface-ui/#/new。连续的 / 会被折叠成一个。

  • Dataway UI 界面中模式切换会因为 // 但行注释问题产生一些不友好的用户体验。现改成 /**/ 多行注释方式。

修复

  • issue Dateway 4.1.3 版本资源文件缺失问题。

  • issue Dataway 修复 spring boot context_path 不支持的问题。

  • Dataway 当关闭 UI 功能之后接口调用报 NPE 问题。Bug 原因是 Dataway 内置 DataQL 的环境是一个隔离环境,隔离环境的初始化是在 UI 之后。

  • 修复 SqlFragment 单行注释判断不识别的问题。

本次更新说一点新鲜的

本次更新带来的众多新特性,例如可以通过 Api前置拦截器做权限判断:

apiBinder.bindSpiListener(PreExecuteChainSpi.class, (apiInfo, future) -> {
    String apiPath = apiInfo.getApiPath();
    String apiMethod = apiInfo.getMethod()
    if (...) {
        // (方式1)通过 future 设置异常信息
        future.failed(new StatusMessageException(401, "not power"));
        // (方式2)或者直接 throw 一个异常
        throw new StatusMessageException(401, "not power");
    }
});
// Result
// {
//   "success": false,
//   "message": "not power",
//   "code": 401,
//   "lifeCycleTime": 42,
//   "executionTime": -1,
//   "value": "not power"
// }

或者实现接口的缓存

public class ApiCacheSpi implements PreExecuteChainSpi, ResultProcessChainSpi {
    private Map<String,Object> cacheMap = ... // for example

    public void preExecute(ApiInfo apiInfo, BasicFuture<Object> future) {
        String cacheKey = ...
        if (this.cacheMap.containsKey(cacheKey)) {
            Object cacheValue = cacheMap.get(cacheKey);
            future.completed(cacheValue);
            return;
        }
    }

    public Object callAfter(boolean formPre, ApiInfo apiInfo, Object result) {
        // formPre 为 true,表示 preExecute 已经处理过。
        // apiInfo.isPerform() 为 true 表示,API 调用是从 UI 界面发起的。
        if (formPre || apiInfo.isPerform()) {
            return result;
        }
        //
        String cacheKey = ...
        this.cacheMap.put(cacheKey, result);
        return result;
    }
}

千呼万唤的多数据源支持也在其中

SQL执行器在 4.1.4 版本之后提供了可以通过 hint 来切换数据源的能力。在没有指定数据源 hint 的情况下数据源采用的是默认数据源,配置多个数据源的方式如下:

public class MyModule implements Module {
    public void loadModule(ApiBinder apiBinder) throws Throwable {
        DataSource defaultDs = ...;
        DataSource dsA = ...;
        DataSource dsB = ...;
        apiBinder.installModule(new JdbcModule(Level.Full, defaultDs));   // 默认数据源
        apiBinder.installModule(new JdbcModule(Level.Full, "ds_A", dsA)); // 数据源A
        apiBinder.installModule(new JdbcModule(Level.Full, "ds_B", dsB)); // 数据源B
    }
}

在DataQL中选择数据源:

// 如果不设置 FRAGMENT_SQL_DATA_SOURCE 使用的是 defaultDs 数据源。
//   - 设置值为 "ds_A" ,使用的是 dsA 数据源。
//   - 设置值为 "ds_B" ,使用的是 dsB 数据源。
hint FRAGMENT_SQL_DATA_SOURCE = "ds_A"

// 声明一个 SQL
var dataSet = @@sql() <% select * from category limit 10; %>
// 使用 特定数据源来执行SQL。
return dataSet();

 

猜你喜欢

转载自www.oschina.net/news/115302/dataway-4-1-4-released