Dataway介绍

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();