apijson json服务编排 #482
Comments
|
@TommyLemon 场景: |
扫描所有字段来识别是否有 transaction 代价太大了。 非 CRUD 方法，都只能和 URL method 完全一致，避免意料之外的安全风险。 话说现有使用方式 "@delete":["Comment"] 麻烦了点，前端传参应该尽可能简化，除非有兼容等严重问题或实现代价太大，APIJSON 所有 key 不支持逗号 , 分号 ; 斜杠 / 反斜杠 \，所以 "@delete":"Comment[],Moment" 并不会有兼容问题。 |
|
|
为了支持跨数据源的事务，需要在 AbstractParser 新增一个 // Map<数据源标识, SQLExecutor 实例>
Map<String, SQLExecutor> datasourceSQLExecutorMap数据源标识同 AbstractSQLExecutor.connectionMap 的 key AbstractParser.getSQLExecutor 根据 数据源标识 get 到非 null 就返回，没有才 createSQLExecutor 然后 put 进 map 再返回； Parser.begin 时只对当前的 SQLExecutor 调用 begin。 Parser.rollback 时统一遍历 datasourceSQLExecutorMap 的所有 SQLExecutor 来 rollback； |
@TommyLemon |
|
如果不是全局事务，那就只有当执行 增/删/改 时开启，执行完马上 commit，碰到下一个 增/删/改 再开启和 commit。 |
|
@TommyLemon 解析顺序
2、非 CRUD 方法，都只能和 URL method 完全一致，避免意料之外的安全风险。 {
"@post": "User:aa",
"User:aa":{
"username":"test-3",
"password": "233223",
"state": 1
},
"tag": "User",
"@explain": true
}
{
"@post": "User:aa,User_address[]",
"User:aa":{
"username":"test1",
"password": "123456",
"state": 1
},
"User_address[]": [
{
"user_id@": "User:aa/id",
"addr": "ddd",
"count": 1
},
{
"user_id@": "User:aa/id",
"addr": "ddd1",
"count": 2
}
],
"@delete": "User:delUser,User_address:delUserAddress",
"User:delUser":{
"id{}": ["b6d7c307-cb82-4780-8361-2509973d88de", "c63d7bd8-cbb8-41f8-9ee0-713f0d30474b","cadeca84-2901-4850-aa36-6672d9d34299"]
},
"User_address:delUserAddress": {
"id{}": ["887edfe9-0206-415d-96de-325d97e248cb", "24eb9e05-d3ef-4661-8d22-c063643f61cd"]
},
"@explain": true
}
|
|
@TommyLemon {
"sql@": {
"@method": "GET",
"with": true,
"from": "User",
"User": {
"@column": "username",
"username": "非id-update-test-0"
}
},
"User": {
"@state": 1,
"password": "123456",
"username{}@": "sql"
},
"explan": true
}WITH `sql` AS (SELECT `username` FROM `housekeeping`.`User` WHERE ( (`username` = '非id-update-test-0') ) )
UPDATE `housekeeping`.`User` SET `password` = '123456_1669605075502' WHERE ( (`username` IN ( SELECT * FROM `sql`) ) ) 你看这么改行不? "User": {
"@state": 1,
"password": "123456"
}update user set password = "123456" where state = 1; |
CRUD 方法，没有声明就用 GET。 |
@State 会被认为是自定义关键词，与现有语法冲突，不合适。 |
嗯嗯,不好意思, 应该先查文档 {
"User": {
"state~": "1",
"password": "123456",
"username~": "test4",
"@combine": "state~ & username~"
},
"explan": true
}UPDATE `housekeeping`.`User` SET `password` = '123456_1669608632896' WHERE ( regexp_like(`state`, '1', 'c') ) AND ( regexp_like(`username`, 'test4', 'c') ) |
@TommyLemon {
"User:aa":{
"username":"test1",
"password": "123456",
"state": 1
},
"User_address[]": [
{
"user_id@": "User:aa/id",
"addr": "ddd",
"count": 1
},
{
"user_id@": "User:aa/id",
"addr": "ddd1",
"count": 2
}
],
"@put": "User_address:modifUA",
"User_address:modifUA":
{
"id": "5e2d528c-106a-4f14-90b2-f27b5943e3e1",
"user_id@": "User:aa/id",
"addr": "addr-01",
"count": 1
},
"@explain": true
}
|
带有查询条件功能符的话，不用声明在 @combine 内，也会作为条件 |
|
json 不用传递 @method, 代码我已经调整 WITH `sql` AS (SELECT count(*) FROM `housekeeping`.`Sys_user_role` WHERE ( (`user_id` = '4732209c-5785-4827-b532-5092f154fd94') ) ) \nSELECT * FROM `housekeeping`.`Sys_role` WHERE ( (`id` IN ( SELECT * FROM `sql`) ) ) LIMIT 1正确语句: WITH `sql` AS (SELECT `role_id` FROM `housekeeping`.`Sys_user_role` WHERE ( (`user_id` = '4732209c-5785-4827-b532-5092f154fd94') ) ) \nSELECT * FROM `housekeeping`.`Sys_role` WHERE ( (`id` IN ( SELECT * FROM `sql`) ) ) LIMIT 1 |
未显示声明 method，默认用 GET，至于参数被吞掉，没有实际执行，这是 bug，改掉就好了 |
|
|
@TommyLemon 你看这里是 不管IS_UPDATE_MUST_HAVE_ID_CONDITION 的值,无法找到引用对象,就抛异常嘛? |
|
累死我了, json支持事物、多条语句执行, http crud支持 很完善了 |
1.GET/GETS/HEAD/HEADS/DELETE 都不会处理 Table[]:[] ，这个没有对应的协议及功能，不用管，用户这么传，原样返回，这是他们用法问题。 2.引用赋值，如果关联的值查不到或者为 null，不能允许继续查询，因为这会导致范围扩大，不符合绝大部分需求，而且有严重的安全隐患，例如 GETS/HEADS/PUT/DELETE 的 id/userId 条件限制因为允许 null 而失效。这不是 bug，是功能特性，所以也不用管。 #467 应该是写法问题 |
可以的 |
|
1.GET/GETS/HEAD/HEADS/DELETE 都不会处理 Table[]:[] ，这个没有对应的协议及功能，不用管，用户这么传，原样返回，这是他们用法问题。 2.引用赋值，如果关联的值查不到或者为 null，不能允许继续查询，因为这会导致范围扩大，不符合绝大部分需求，而且有严重的安全隐患，例如 GETS/HEADS/PUT/DELETE 的 id/userId 条件限制因为允许 null 而失效。这不是 bug，是功能特性，所以也不用管。 |
|
我看了apijson elasticSearch demo. 引入 elasticsearch-sql. json里面配置多数据源,我测一下 |
这个通过 APIAuto 来解决吧，新增一个提示。类似 @Explain: true 也不返回，这个是 bug，可以在 AbstractObjectParser 中处理下 |
|
@TommyLemon |
1、Elasticsearch-SQL 不支持增删改的话，APIJSON 也先不急着支持，用户可以用 RESTful API 的方式自己实现。后续如果这方面需求的用户比较多再考虑。 /refresh 这种接口也让用户自己调用。APIJSON 暂时先主要支持最核心也最常用的查询功能。 2、截屏的代码没有用 APIJSON，可以用 APIJSON 再试试。 |
|
之前改 bug 等源码变更，可以先提交 PR 哦，有了 fork 项目，提 PR 只需要 Git 推送到 fork 项目，然后点 Contribute > Open Pull Request，例如
|
|
@TommyLemon |
|
@TommyLemon |
|
2、用户直接调用 Elasticsearch 的官方 API（目前是 RESTful API）实现增删改、初始化、权限管理等，也可以用配套的管理界面或 CLI 等。 执行方法是指 SQL 函数？远程函数？还是存储过程？如果是前 2 者应该都没问题，至于存储过程看 Elasticsearch 是否支持。 这个第三方库倒是支持 SQL 语法比较全，不过 新增和修改 看文档还不支持，可以对比下官方的，看情况决定用哪个。 |
赞，也可以通过 SQL 语法支持 APIJSON 对接 Redis 了。 |
|
notDeletedValue 目前看起来没必要， |
@TommyLemon 查询支持 |
|
@cloudAndMonkey 现在可以取消 isQueryMethod 这个限制了。
https://github.com/Tencent/APIJSON/blob/master/Document.md#3.2 |
请问PUT 条件修改 json 如何实现 where a = "" 呢？ |
|
@cloudAndMonkey "@combine": "a" 强制指定 "a": "" 为条件， |
{ "msg": "User_address:{ @combine:'user_id' } 中字符 'user_id' 对应的条件键值对 user_id:value 不存在！" 这个和apijson解析顺序有关， 如果要实现"h@combine": "a" 强制指定 "a": "" 为条件，需要调整解析顺序，还要考虑是否有其他影响？ |
|
@MethodAccess |
|
这个不方便用注解实现，直接用一个 Map 存假删除配置就行，虽然字段在一张表，但代码中配置可以分离 |
哈哈，已经弄好了 |
应该是解析到 @combine 时是从 Map<String, Object> where 中取值，但 PUT user_id 是放在 Map<String, Object> content 中， 有两个 getWhereString 方法都需要多传一个参数 content，然后有个再传给 parseCombineExpression |
|
@TommyLemon |
|
@TommyLemon |
|
|
条件键值对都放在 wehre，PUT(UPDATE) 赋值键值对都放在 content，POST(INSERT) 赋值键值对都放在 values |
应该只有 "@combine":"a | (b & c)" 这种逻辑表达式才会出现以上 bug，只需要改 parseCombineExpression 相关的。 因为 "@combine":"a,b,&c,!d" 这种简单组合方式已经提前处理过了： 解析表达式比较复杂，所以这里就没有提前处理了，还是简单的加个 content 参数再加上 |
|
加了个用户业务侧自己使用 Redis 缓存的 Demo |
|
@TommyLemon |
@TommyLemon 这里需要将key 和 combineExpr 表达式进行比较，或者 将combineExpr表达式进行解析获取字段名，然后进行比较？ |
可以在启动后、init 前 REDIS_TEMPLATE.discard(); 清空缓存，但更好的方式是不缓存 APIJSON 配置表，毕竟数据量非常有限，而且很少更新（尤其是相当于业务表，更新频率低很多）。 |
直接 combineExpr.contains(key) 会有误判，例如 "admin_user_id | name".contains("user_id")， 可以按这个逻辑来判断，key 左侧、右侧可能的字符不能和它拼接成一个有效的键名 |
收到，我改一下 |
|
@TommyLemon 我把这个地方改一下，调用一个方法哈 |
|
搞完了， 累死了 |
|
|
可以的 |
|
|
哈哈，感谢~ |
TommyLemon
added
Enhancement 增强
Description
@TommyLemon
功能描述:
一个服务编排的伪码流程设计
将伪码转换为 apijson json、前置、后置函数、javascript、redis、elasticSearch等
并且能够mork每一步,执行中间流程,还能查询每个阶段执行的sql语句,及结果.
json格式:
1、独立定义一个url method, 通过解析不同method执行不同流程
和已有method区分开,避免歧义
2、最外层新增传参 "transaction": true 来指定开启事务
3、控制每条语句的数据源
4、完善 “@Explain"
如果没有执行计划,则返回sql语句. 能够在 reponse返回值中, 看到json中执行的每条sql,方便排错
5、@Version支持
定义不同场景的 新增、修改、删除等执行规则. 请通过version版本区分
6、前置函数
组装数据, 调用对应数据源的api方法执行即可
把一些计算, 执行,计算 等 放到一个函数进行整合
还没细化
7、支持mork
通过伪码,分解为不同 阶段 的json语句执行
测试点:
1、测试 一个json多条语句,后置函数啥时候执行
2、操作其他数据源, 事物是json执行完才会提交, 需要保证一致性
3、redis、elasticSearch、javascript、lua等功能测试
The text was updated successfully, but these errors were encountered: