mirror of
https://github.com/nocobase/nocobase
synced 2024-11-15 10:46:54 +00:00
docs: improve documentation of core modules
This commit is contained in:
parent
0a1e8a8b1e
commit
17982847b5
@ -552,6 +552,7 @@ registerModel('test', Test);
|
||||
|
||||
db.table({
|
||||
name: 'tests',
|
||||
model: 'test',
|
||||
});
|
||||
|
||||
const Test = db.getModel('tests');
|
||||
@ -593,7 +594,7 @@ database.import({
|
||||
database.isDefined('foos'); // false
|
||||
```
|
||||
|
||||
### Operator.register <Badge>实验性</Badge>
|
||||
### Operator.register <Badge>实验性</Badge> <Badge>待完善</Badge>
|
||||
|
||||
注册自定义 op
|
||||
|
||||
@ -672,11 +673,10 @@ db.extend({
|
||||
});
|
||||
```
|
||||
|
||||
<Alert title="datatable.table 与 database.extend 区别?" type="warning">
|
||||
datatable.table 用于初始化,datatable.extend 用于处理扩展,需要存在 table 已存在。
|
||||
<Alert title="database.table 与 database.extend 区别?" type="warning">
|
||||
database.table 用于初始化,database.extend 用于处理扩展,需要 table 已存在。
|
||||
</Alert>
|
||||
|
||||
|
||||
### database.isDefined
|
||||
|
||||
判断数据表是否已定义
|
||||
@ -740,12 +740,12 @@ await db.sync({
|
||||
|
||||
更多参数参考 [Sequelize.sync](https://github.com/sequelize/sequelize/blob/5b16b32259f0599a6af2d1eb625622da9054265e/types/lib/sequelize.d.ts#L45)
|
||||
|
||||
<Alert title="datatable.sync、table.sync、sequelize.sync、Model.sync 区别?" type="warning">
|
||||
<Alert title="database.sync、table.sync、sequelize.sync、Model.sync 区别?" type="warning">
|
||||
|
||||
- datatable.sync:所有已配置表同步,可以指定 tables 范围
|
||||
- database.sync:所有已配置表同步,可以指定 tables 范围
|
||||
- table.sync:当前表同步,如果有关系字段,关系表也会处理
|
||||
- sequelize.sync:所有 sequelize.models 同步
|
||||
- Model.sync 只处理某个 Model.attributes 同步
|
||||
- Model.sync 只处理某个 Model.attributes 同步,并不处理关系 Model 的情况
|
||||
|
||||
</Alert>
|
||||
|
||||
@ -802,7 +802,7 @@ const fields = table.getOptions('fields');
|
||||
|
||||
### table.addField
|
||||
|
||||
新增字段(附加操作)
|
||||
新增字段(附加操作),字段的配置参考 [Field Types](#field-types)
|
||||
|
||||
```ts
|
||||
const table = db.table({
|
||||
@ -1020,7 +1020,7 @@ await post.updateAssociations({
|
||||
{
|
||||
id: 1,
|
||||
status: 'publish',
|
||||
user: { // 关系数据,可能需要查询之后获取
|
||||
user: { // 关系数据,可能需要异步获取
|
||||
id: 1,
|
||||
email: 'admin@example.com'
|
||||
},
|
||||
|
20
docs/cores/packages/migrator.md
Normal file
20
docs/cores/packages/migrator.md
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
title: '@nocobase/migrator'
|
||||
order: 8
|
||||
# toc: menu
|
||||
---
|
||||
|
||||
# @nocobase/migrate <Badge>未实现</Badge>
|
||||
|
||||
NocoBase 的 Database 是基于 Sequelize,Sequelize 虽然提供了 sequelize-cli,包括 migrations 和 seeders 但是并不适用于 NocoBase。
|
||||
|
||||
- Sequelize 的 migration 只有 queryInterface,但是 NocoBase 考虑的更多是配置层面问题
|
||||
- 要考虑 Upgrade 层面的问题,比如 0.3 升级 0.6、0.4 升级 0.6、0.5 升级 0.6 等等一系列问题
|
||||
- 需要考虑插件里的 migrations
|
||||
|
||||
目前已知的开源项目里,Ghost 团队实现的 [knex-migrator](https://github.com/TryGhost/knex-migrator) 非常接近我们的需求。Ghost 的 [migrations](https://github.com/TryGhost/Ghost/tree/v4.2.2/core/server/data/migrations) 例子。
|
||||
|
||||
虽然非常接近,但也存在一些差异:
|
||||
|
||||
- NocoBase 的 database 用的是 Sequelize 而不是 Knex
|
||||
- NocoBase 的配置更复杂,我们要为此提供一些简易的 API 辅助完成 migrate
|
@ -68,7 +68,7 @@ api.resource('users').login({
|
||||
});
|
||||
```
|
||||
|
||||
<Alert title="为什么不是 REST 或 GraphQL?" type="warning">
|
||||
<Alert title="为什么不是 REST 或 GraphQL?" type="info">
|
||||
|
||||
Resourcer 是基于资源设计的,可以看做是 REST 的扩展(兼容的同时,但有些许不同),提供了类 REST 的 Resource Action API([点此查看细节](#resourcerkoarestapimiddleware)),非常灵活,同时弥补了 REST 的一些缺陷。不用 GraphQL 的原因是因为还不够完善,尤其为了追求 GraphQL 需要写很多代码,并不适合作为常规 API 开放给大众。后续如果反应强烈会考虑适配 GraphQL,其他感兴趣的开发也可以自由发挥,来完善 GraphQL API。
|
||||
|
||||
@ -260,7 +260,7 @@ resourcer.define({
|
||||
|
||||
判断资源是否已定义
|
||||
|
||||
### resourcer.koaRestApiMiddleware
|
||||
### resourcer.koaRestApiMiddleware <Badge>待完善</Badge>
|
||||
|
||||
原 resourcer.middleware
|
||||
|
||||
@ -445,12 +445,12 @@ POST /api/users:login
|
||||
|
||||
<Alert title="注意" type="warning">
|
||||
|
||||
在 Resource Action API 的设计理念里,即使类似 login、register、logout 等非标准的 REST API 也可以非常方便的扩展。大家可以更专注于 action 本身,而不必纠结于 request method 和 route 应该如何设计,也不需要考虑 routes 优先级等问题。
|
||||
在 Resource Action API 的设计理念里,即使类似 login、register、logout 等非标准的 REST API 也可以非常方便的扩展。大家可以更专注于 action 本身,而不必纠结于 request method 和 route 应该如何设计或派发,也不需要考虑 routes 优先级等问题。
|
||||
|
||||
</Alert>
|
||||
|
||||
|
||||
### resourcer.registerAction(name: ActionName, options: ActionOptions)
|
||||
### resourcer.registerAction(name: ActionName, options: ActionOptions) <Badge>待完善</Badge>
|
||||
|
||||
原 resourcer.registerActionHandler
|
||||
|
||||
@ -518,7 +518,7 @@ resourcer.use(async (ctx, next) => {
|
||||
});
|
||||
```
|
||||
|
||||
### resourcer.registerActions(actions)
|
||||
### resourcer.registerActions(actions) <Badge>待完善</Badge>
|
||||
|
||||
原 resourcer.registerActionHandlers
|
||||
|
||||
@ -549,6 +549,13 @@ resourcer.registerActions({
|
||||
|
||||
注册 resourcer 全局 middleware
|
||||
|
||||
```ts
|
||||
resourcer.use(async (ctx, next) => {
|
||||
// code...
|
||||
await next();
|
||||
})
|
||||
```
|
||||
|
||||
<Alert title="为什么要提供不同的中间件注册方法?" type="warning">
|
||||
|
||||
虽然大部分框架都提供了中间件,但是中间件的执行顺序(优先级)依赖于编码顺序,这种方式非常不利于插件化管理。因此,在 Resourcer 设计思想里,将中间件做了分层,不同层级的 middlewares 不依赖于编码顺序,而是如下顺序:
|
||||
@ -558,6 +565,6 @@ resourcer.registerActions({
|
||||
3. 再次,resource 层(每个资源独立):`resourcer.registerActionMiddleware`
|
||||
4. 最后,action 层:`resourcer.registerResourceMiddleware`
|
||||
|
||||
不过,每个层次的中间件执行顺序还依赖于编码顺序,如有需要再进行更细微的改进。
|
||||
不过,每层的中间件执行顺序还依赖于编码顺序,如有需要再进行更细微的改进。
|
||||
|
||||
</Alert>
|
@ -4,7 +4,7 @@ order: 3
|
||||
# toc: menu
|
||||
---
|
||||
|
||||
# @nocobase/sdk
|
||||
# @nocobase/sdk <Badge>待完善</Badge>
|
||||
|
||||
## 介绍
|
||||
|
||||
|
@ -3,7 +3,7 @@ title: '@nocobase/test'
|
||||
order: 7
|
||||
---
|
||||
|
||||
# @nocobase/test
|
||||
# @nocobase/test <Badge>未实现</Badge>
|
||||
|
||||
## mockDatabase
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user