GitLab

Created by: hotlong

欢迎大神加入，上面提到的很多问题确实是我们要改进的内容。

目前有以下几点是2.0正在处理的：

我们新开了一个app-builder的项目，作废meteor和creator，重写前端。暂时的进度核心控件已经实现替代。前端列表控件替换为 ag-grid，表单控件替换为 ant design pro components 。下一步整个前端可以重写。
权限继承方面，我们计划实现 salesforce 基于 role 上下级关系的权限继承。
公式的部分如果想真正实现类自然语言非常难，应该是一个独立的项目，暂时不在考虑之内。况且我们认为目前所有的无代码系统能实现的能力非常有限，完整的业务场景一定是需要程序员加入配合的，很多需求用华炎魔方写公式至少要比写代码要简单太多。
数据库的通用性方面，暂时不考虑内核支持传统数据源。NoSQL有天生的好处例如树状结构的数据，这是传统数据库不具备的。

Created by: snowyu

我们新开了一个app-builder的项目，作废meteor和creator，重写前端。暂时的进度核心控件已经实现替代。前端列表控件替换为 ag-grid，表单控件替换为 ant design pro components 。下一步整个前端可以重写。

Ok, 抽空我瞧瞧.

权限继承方面，我们计划实现 salesforce 基于 role 上下级关系的权限继承。

我对salesforce研究得不多, 感觉salesforce的层级权限继承的架构设计有点不好理解,不是很通用. 比如role的处理的资源对象只有三类: contacts, opportunities, and cases,这明显不合理(可能是初期CRM的遗留问题). 然后又搞了个莫名的Sharing Rules,还有Group. 另外salesforce似乎并没有实现组织的权限继承,只有分区(Divisions).

一般来说Role不就应该是权限和(子)角色列表么? 而权限则是对资源对象的操作约束. 例如,如下的权限表,就可实现字段限制和过滤器限制,以及角色继承复用(我的第三版角色权限规范):

自有编辑: # 只能查看编辑自己创建的 - 权限模板
  - ".view#creator == ${self}"
  - ".edit#creator == ${self}"
自有管理: # - 权限模板
  - 自有编辑
  - ".delete#creator == ${self}"
$everyone:
  # 能创建帐号
  - "Account.add"
  - "自有管理": # 如果存在参数列表,那么参数列表的值将覆盖原有角色权限表中的值
    # 不能编辑查看Account资源的 password 和 isVerified 字段
    - "Account[!password, !isVerified]"
  # 能改变自己的密码
  - "Account.changePassword#creator == ${self}"
员工权限: # - 权限模板
  # 可以对任意资源进行查看
  - "*.view"
  # 限制住 Account 资源的
  - $everyone
员工: # 职务
  - "员工权限"
  # 并且不包括订单资源的
  - "!Order"

当然限于对salesforce的了解有限,如有谬误,随时指正.

以上没有包括针对组织的权限继承,而我说的组织的权限继承,其目的是让组织可以自行管理自己子组织及子组织资源，完全控制自己的权限。其默认的基本原则是:

上级组织可以查看下级组织的资源
下级组织无法查看上级组织的资源

当然原则是可以打破的,我引入了资源的查看能力,来进一步约束资源的可见度:

资源查看能力的定义如下（数值越大，能力越大）：

0 公开: 面向大众（互联网）公开。
10 组织内公开: 本组织内以及该组织的下级可见
20 特殊组织内公开: 本特殊组织（最左边开始的第一个，或者说第一个特殊组织）内以及特殊组织的下级可见
30 本组织内公开: 本组织内可见(不含下级)以及本组织的特殊组织内可见(含特殊组织的下级)。
40 本特殊组织可见: 仅限本特殊组织（最右边开始的第一个，或者说最后一个特殊组织）内可见(含该特殊组织的下级)。
50 只是本组织可见，不包含任何下级组织，无论是普通组织的，还是特殊组织的。
255 绝密

公式的部分如果想真正实现类自然语言非常难，应该是一个独立的项目，暂时不在考虑之内。况且我们认为目前所有的无代码系统能实现的能力非常有限，完整的业务场景一定是需要程序员加入配合的，很多需求用华炎魔方写公式至少要比写代码要简单太多。

是的,可以跨项目使用的独立项目.于我来讲,这块难点就是语法规范的定义费思量,其它部分还好.所以准确的说是低代码系统,不过针对特定领域来说,还是蛮有效的. 真正复杂的需求,还是要添加新的方法,触发器. 至于表达式能简单点就简单点,不是更好. 超越也是从点滴做起的.

数据库的通用性方面，暂时不考虑内核支持传统数据源。NoSQL有天生的好处例如树状结构的数据，这是传统数据库不具备的。

尽管我个人也比较倾向NoSQL,但是还是有不少客户需要关系式数据库. 越是通用的项目,那么越要解决不同的底层需求. 其实这块只要有一个好的ORM顶在前面,支持常见的数据源并不太难. 只不过关系式数据库的弊端是不能联机升级数据库,升级migration时只能offline.

另外对于ORM,不推荐TypeORM,它已经正式决定不支持动态 database schema,issue都关了. 我更推荐MikroORM,数据源基本通吃,动态schema,事务,migration,性能也不错.我准备基于此重写Moleculer DBAdapter.

Created by: snowyu

I have been busy with other things recently and haven’t tracked the MikroORM's progress for a while.

It can query multi-databases directly with the same connection:

Cross-database joins and cross-schema joins

Multi connections way here:

Multiple database connections

Created by: dzcpy

@snowyu Thanks for your reply. I've done a bit of research, but sadly enough, MikroORM only supports querying from different schemas dynamically, but not inserting data into a specific schema with its entity manager or repository. There is workarounds like using a query builder, but in that case all ORM related features are not available.

GitLab

[Proposal]: 问题与展望

问题

展望

菜单

[Proposal]: 问题与展望

问题

展望

相关议题 ...

相关合并请求

相关议题
...