Packing 的用途就是把一堆通常放一起的数据打包的意思。 这样做的目的就是降低交互。 还是用姓名这个间的的例子，为了我们能够拆分姓和名，我们通常有 Item 姓和 Item 名。 为什么这样，英文和中文其实差不多的，中文有复姓，比如说欧阳。 用名字：欧阳锋来举例。 那么我们针对姓名，我们在姓字段存储欧阳，名字段存储 锋。 如果我们需要获得完整的姓名，那么我们就可以把这 2 个 Item 打包在一起，给一个新的 Item 叫做 姓名。 这个与 SQL 数据库中字符串拼接函数有点类似，我们通常不会把姓名再存储一遍，如果需要从 SQL 数据库中查姓名的话，我们会用字符串拼接的方式把姓和名加在一起。 SuperItem SuperItem 上面定义的姓名就被称为 SuperItem。 SuperItem 就是 Item Packing 后的结果。 SuperItem 有自己的 Item ID SuperItem 会被系统指派一个自己的 Item ID Add Type 和数据类型 Packing 的 item 必须要有相同的 Add Type。 对于不同的 Add Type，我们是不能 Packing 在一起的。 对于具体存储的数据来说，我们对数据类型或者 Response Type 不做要求，可以相同也可以不同。 limited‐line / unlimited‐line limited‐line 使用格式 (Single, Multiple, Related) unlimited‐line 使用格式 (Multiple, Related) 对于使用 Related‐Multiple 的 Item 是不能够 Packing 的。   https://www.isharkfly.com/t/iris-chronicles-packing/15564

Discourse 是可以修改用户名的，但用户修改自己的用户名会有时间的限制。 这是因为根据官方的说法就是当用户修改用户名后可能会导致内容的失效等问题。 在默认的安装配置下，用户可以在完成注册后的 3 天自己对用户名进行修改。     3 天以后，用户就不可以自己对用户名进行修改了。 管理员配置 当然管理员是可以对 用户名进行修改的。 用户需要告诉管理员他自己希望修改的用户名是什么，管理员可以在后台帮助用户之间进行修改。 如果管理员允许自己对用户名进行修改的话，管理员可以把上面的参数设置为足够大。比如说 3650。 上面参数的限制为天。   https://www.isharkfly.com/t/discourse/15578

和 DISCUZ 不同，DISCUZ 可以允许分类下面还有分类，再继续分类这种嵌套式分类。 Discourse 最多只允许有 2 个分类。 如果你在已有的分类下再继续分类的话，系统会提示错误：     意思就是子分类不能再分子分类。 Discourse 尽量采取了扁平结构，所以标签的作用比分类更大。   https://www.isharkfly.com/t/discourse/15577

Response Type 在关系数据库中可能没有这个选项，我们对关系数据库表中的数据返回的数据就是是数据，通常不再做过多定义。 但是 IRIS 会对返回的数据也做一些定义，这个就是我们说的 Response Type。 Single （单一） 这个好说，就是返回一条数据。 这个就和我们的关系数据库差不多，你返回的数据就是数据，不管你这个数据是多少行。 Multiple （多条） 这里就好像有一个映射关系了。 类似于关系数据库中的 1 对多的关系。 比如说感冒症状，这里可能会有咳嗽，发烧，肌肉酸疼等症状，所以在这里需要返回多条。 如果我们对应关系数据库，把上面的症状全部存储到一个表中，那么这里不就是 1 对多的关系了。 Related 这个就有点绕了。 Related 首先和 Multiple 类似，是可以有多条记录。 但这里需要注意的是，数据的组成是通过 2 个或者多个 Item 打包在一起的。 举例来说，电话，我们首先有一个 Item 定义的是电话类型，另外一个 Item 定义的是电话号码，在实际上我们会把这 2 个 Item 放在一个 Group 里面，这个叫做 Packing。 如果我们有一个数据 需要同时返回这个 Group 中的这 2 个，同时这个 Group 中的数据又是一一对应的，我们就可以说这个返回的数据是 Related。 Related‐multi 相对 Related 更进一步。 Related 是一行对应的一行的数据，Related‐multi 在 Related 的基础上每一行对应多行的数据。 上面的图片就比较好的说明了我们对返回的数据的限制。 这里有个坑，就是 200 和 210 的关系。 如果 210 对应过敏的反应只有一种的话，那么 200 和 210 都是 Related。 但实际上对过敏的反应可能有多钟，比如说对于 Thyme（百里香）的过敏反应有昏睡和发烧。 那么实际上我们就把 200 和 210 拆分开了，200 还是 Related，我们把 210 细化成了 Related‐multi。 https://www.isharkfly.com/t/iris-chronicles-response-type/15562

根据我们前面说的 Item 中的 Add Type 属性，这个主要用来标识输入的数据是不是随着时间的变化而变化，有下面 3 种选项。 No‐Add 这个就是当数据输入后，是不会再变化了，不会随着时间的变化而变化。 Response Each Time 这个就是每次在数据在创建的时候都有可能会变化。 比如说体重，当你每次和医生见面的时候，你的体重都有可能会发生变化。 Lookback 从字面上来看这个就是查找时间。 这个 Response Each Time 对比起来的不同就是修改的频率。 还是用体重来说，每次你重新去看医生你的体重都有可能会变化，但是可能你还是看的是同一个医生。 为了节约存储空间，对医生这个字段我们就可以设置为 lookback，这样的话只要和上次看的医生相同，那么数据显示的就是上次的医生名字，虽然我们这里什么都没有输入。 如果上次看的医生没有的话，那么这里就会显示为 NULL。 针对上面的情况，在 Lookback 中又细分了 2 类：with 和 without deletion。 Lookback with deletion 这种约束允许 Lookback 中的字段内容为空。 用实例来说，就是每次你去医院看医生的时候，可能这次和上次的医生是不一样的。或者说上次你来医院的时候没有看医生，只是做了一个 CT 检查，这个时候医生的字段是空的。 那么我们的 Lookback 的时候，上面有关医生的关联数据就删除了，那么数据在查询的时候就会显示为 Null，我们用 “” 来表示。 Lookback without deletion 这种约束不允许 Lookback 中的字段内容为空。 用一个例子来说明的就是对于个人的婚姻状况，这个状况是可能随着时间的变化而变化的，但是不管是那种婚姻状态，这种状态必须会保持，不能说婚姻状况为空的情况。 当然病人是可以拒绝提供婚姻状态的，哪怕是这种情况，我们也会设置为状态为拒绝提供，从数据的角度来看，这个数据是不可能为 Null 的。所以我们可以设置为 Lookback without deletion。   https://www.isharkfly.com/t/iris-chronicles-item-add-type/15561

IRIS 的数据类型比较少，也就 4 个数据类型：字符串，数字，时间，分类。 在这里分类有点像我们的下拉选择框，其实对应 Java 或者其语言中的数据来说可以说是枚举类型。 只是 IRIS 的枚举类型是定义在数据库中的，并且是事先定义好的。 String 这个好说，就是字符串。 因为 M 语言的限制，所以 String 字符串中可以存储的字符最多为 32KB、 Number 数字，这个数字可以是整数也可以是浮点数。 IRIS 对存储的数据库如果有没有意义的 0 的话，数据库会对这个数字进行处理，删除掉没有意义的 0。 例如数据 “0900.0100” 将会被实际存储为 “900.01”。 时间 时间中我们有 3 个子分类，分别为日期，时间和时间戳。 Date 日期 在 Date 日期中，IRIS 只会存储当前的日期，这个日期是没有时间的。 Time 时间 Time 这个字段只能存储时间，这个时间包括小时和分钟和秒等。 Instant 时间戳 这个时间戳包括有日期，时间和时区。 这个是系统自动生成的系统时间，通常不需要我们认为的手动输入。 Category 分类 这个就是我们说的分类了，在这个分类中我们可以想象为数据库中预先存储的枚举类型。 比如说人的性别，我们通常会预定义好。   https://www.isharkfly.com/t/iris-chronicles-data-type/15559

Item 在 IRIS 中的作用和我们关系数据库中有关字段的作用的相同的，可以通过定义 Item 的属性，我们可以知道我们的可以存储什么的数据，以及数据之间有什么关系。 Item number 每一个 Item 都会有一个 ID，这个 ID 是为唯一在数据库中用来标识 Item 的，这个 ID 通常是数字。 Item Title 类似关系数据库中的字段名。 比如说我们定义一个用户名字段，为了标识用户名，我们可以把 Item Title 设置为 UserName。 Data Type 定义我们可以在数据中存储什么样的数据。 比如说我们可以存储字符串，数字，或者时间等等。但 IRIS 的字段类型有限，也就那么4种，所以在这里我们只知道这个是定义数据类型的就行了。 Networked（可选） 这个就有点像我们关系数据库中的跨数据库了。 例如在关系数据库中，我们有数据库 A 存储了一些数据，但我们在数据库 B 中希望引用数据库 A 中的数据，那么我们 SQL 上通常是 a.col 字段名这种方式来引用的。 如果这里标识的的是 Networked 的话，那么意味着这个 Item 中的数据需要通过网络方式从其他数据库中获得数据。 Add Type 这个也是对数据来进行定义的，表示的是存储的数据是不是随着时间的改变而改变的。 针对病人的数据来说的，病人的血型是不会随着时间的变化而变化的，所以 Add Type 的值为 No-Add。 别和我说当病人做了干细胞移植后血型会发生变化，这个字段应该会变化的，这不是抬杠嘛。 Response Type 在这里定义我们的数据是什么样的数据。 我们数据是 1 行还是 2 行，甚至是不是多行。 在这里这个可能不好理解，那么我们用数据来说明。 考虑下姓名，如果我们把姓名作为一个完整的字符串的话，那么 Response Type 就应该设置为 1，如果是姓名是分开姓和名的话，那么 Response Type 就应设置为 Multiple。 Indexed（可选） 用来标识 Item 中的数据是不是添加到索引中。 按照 EPIC 的说法，貌似是所有数据都会添加到索引中。 Packing（可选） 这个叫做打包的意思。 这个意思就是把一堆数据打包在一起，还是用姓名这个数据来说说。 我们可以把姓存为一个 Item，同时把名存为一个 Item。 然后我们把这 2 个 Item 打包放在一起就可以做一个 Packing 姓名了。这样的好处就是可以节约存储空间。 https://www.isharkfly.com/t/iris-chronicles-item/15558

对于我们用得最多的关系型数据库来说，首先有的是数据库名字，然后是表名字，然后就是字段名，随后就是一条一条的数据。 对于 IRIS 来说，因为是使用的层级数据库，所以上面的定义就不能完全的照搬了，而且不建议想象成一样，因为我们没有办法最后完全的对应上。 我们最好的是把 IRIS 想想成一个文件存储柜，如下面的图。 上面的柜子的抽屉是一个一个的文件夹，然后文件夹里面夹的是一张一张的纸，纸上面存有我们的数据。 这里有些名词需要重新定义。 第一层 Database（Master file） IRIS 中定义的数据库不是这一个大柜子，而是我们上面的那个抽屉。 EPIC 上面的抽屉定义了 800 多个，等于你安装一个 EPIC 系统，系统初始化的时候就会有 800 多个数据库帮你初始化了。 EPIC 系统中的数据库使用的是 3 个大写英文字母表示的，这 3 个英文字母在他们的系统中都有特定的意义，所以不能随便修改。 这个数据库的名称，EPIC 称为 INI，其实使用的是英文单词 Initials（简写）的 3 字母表示的。 如果你是使用 Windows 系统的话，我们知道很多系统的配置文件都用 .ini 表示，所以这里需要明确的就是数据库的名称不是系统文件。 第二层 Record IRIS 定义第二层为 Record，实际上 就是你在每个抽屉中放的一个一个的文件夹。 以病人的病历为例，上面每一个病人就会使用一个文件夹来装病人的数据。 假设你今天来我们医院看病了，但是你从来没有来过，那么我们在你班里手续的时候就会为你创建一个账号，这个账号就是对应这里的 Record， 对应实际的内容就是抽屉里面放的文件夹。 英文在这里会有歧义，如果你对应关系数据库的话， Record 表示的是表中的一条一条的记录。在这里也可以这么想，但因为缺少了一层，所以 Record 的级别提高了。 因此最好不要用关系数据库中的表来对应。 第三层 Contract 当我们有文件夹了，那么下一步就是放一张一张的纸，在这一张一张的纸上面有我们的数据。 那么这一张一张的纸就叫做 Contract。 这个英文单词在这里又有歧义了，因为和中文翻译合同是同一个词。但在这里没有合同的意思，所以只能最好使用英文原词来避免歧义。 第四层 数据 Items 对我们来说最重要和有价值的就是数据了，所以在 Contract 的这张纸上面我们就放的是数据。 对于数据来说，通常我们可以放各种数据，比如说我们在纸上面画一个表对吧。 但 IRIS 在这里就不这样用了，IRIS 只能在纸上面放 K-V 数据库，就等于是一个一个的键值对的意思。 与数据库对应来说就是 Map 了。 在 Map 中的 K，我们通常使用的词是 Key，但 IRIS 用的单词是 Item。 Item 就是定义 Map 中的 Key，通过这个定义来约束 Value 能够存什么样的东西，这个类似我们关系数据库中在表里面定义的字段，通过这个定义的字段来对可以存储的值来进行约束。 Value 这个好说，就是对应我们 Map 中的 Value，这个 Value 就是我们存储具体数据的地方。 对应关系数据库就是我们的一个一个的数据了。 总结 通过对上面的表述，大家应该对 IRIS 是如何对数据存储结构进行表达有所了解了。 https://www.isharkfly.com/t/iris-chronicles/15557

最近我们在想使用我们提供的代码库进行元数据提供的时候，启动的服务报 CORS 问题。     如果你的 Gitea 服务器是直接暴露给外部使用的话，可以在 Gitea 的配置文件中添加下面的配置： [cors] ENABLED = true ALLOW_DOMAIN = * 在完成上面的配置修改后，需要重启 Gitea 服务器来让设置生效。 需要注意的是，如果在这个时候还使用反向代理，那么针对 CORS 的限制是不在 Gitea 服务器上，而是在反向代理服务器上。 因此对 Gitea 的修改不能起到允许 CORS 的作用。   https://www.isharkfly.com/t/gitea-cors-access-control-allow-origin/15553

我遇到了一个问题就是 Nginx 是作为反向代理服务器部署的，但因为 Nginx 的配置导致 CORS 问题。 在这个时候我们可以对 Nginx 的配置文件进行修改： 在 location 后添加下面的内容： add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS'; add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';     如上图显示的内容，当完成上面的修改后重启服务器。 那么你的 Nginx 服务器将不会对访问的域名进行限制。 当然你也可以对特定的方法进行配置，例如我们只希望 Get 方法没有这个限制的话，就可以在上面的示例配置中只设置 Get 方法。 为了安全起见，我们还是希望 POST 方法是 CORS 限制的，因为我们不希望任何和我们无关的数据进入我们的系统，来提高安全性。   https://www.isharkfly.com/t/nginx-cors/15554