博客专栏的设计

01 概述.series.md

博客专栏的设计

之前的一篇文章中有讲过，我的博客的编辑和导入是基于Gist的。

形式是每当有Gist更新或新建的时候，在其中寻找文件名符合 *.blog.md 的文件，如果有的话，认为其是博客文章，并自动同步到数据库。

现在要在博客中建一些专栏，为了方便维护，Gist存储的方式和数据库中存储的方式也要做一些调整。

以前的格式

以前每篇Gist中会带一个文件，文件名为 *blog.md。

每个 blog.md 文件中，会用Markdown 注释的方式，写入一些分类、标签等信息。

新的格式

要做专栏的话，文章的关联性就很重要了。如果随意地存储，仅通过文章的标题或分类进行管理，则在展现的时候较难处理，且编辑的时候较难维护。

我的想法是既然Gist支持多个文件，那么专栏的文章就可以写在同一个Gist之中，方便维护。

形式如下：

1. Gist中第一个文件，以 *.series.md 方式命名，在其中写入一些注释信息，标注此Series的一些信息（名称、描述等）。
2. Gist中其它的文件，还以 *.blog.md 方式命名，形式和以前相同。

后台数据存储

后台数据需要做如下两方面的改动：

1. 添加Series表
2. Posts表中添加SeriesId字段

数据同步方式

在文章的同步方式上，也需要做一些修改。

之前的同步方式会假设一个Gist中只有一个文章，现在要能正常处理一个Gist中多篇文章的情况。

02 多文件同步.series.md

Gist中多文件的同步问题

上面有提到，想要在一个Gist中添加多篇博客文章，实现专栏的效果。

同步的时候，自然也需要做一些相应的修改。

文件唯一标识

Gist的接口中，对于多文件，会返回如下内容：

"files": {
  "first-file.series.md": {
    "filename": "first-file.series.md",
    "type": "text/markdown",
    "language": "Markdown",
    "raw_url": "https://gist.githubusercontent.com/banyudu/9524f2486ec498e57cf6201680005a8c/raw/15fb1b41aea54c13333031247db319fcbc80f94c/first-file.series.md",
    "size": 17
  },
  "second-file.series.md": {
    "filename": "second-file.series.md",
    "type": "text/markdown",
    "language": "Markdown",
    "raw_url": "https://gist.githubusercontent.com/banyudu/9524f2486ec498e57cf6201680005a8c/raw/d2dccd05f6dfb4700154bb5e7b8db8906437a9df/second-file.series.md",
    "size": 7
  }
},

从上面可以看到，files中没有什么唯一id之类的东西，只有 filename 和 raw_url 有可能被作为唯一标识。

最开始我想到用 raw_url 中的 "raw" 和 文件名之间的一串id作为其唯一标识，但是实验发现，这串id是代表的历史版本信息，每次编辑文件之后，这个信息会发生变化。所以不能用它来唯一代表文件。

那文件名呢？

我测试了下将在同一个gist中添加两个相同的文件名，会发生下面的报错：

说明文件名是唯一的。

那么我们就可以将 gistId + filename 作为一篇博客的唯一标识。raw_url 作为其内容是否有更改的判断依据。

文件增删及更新的处理

Gist中的文件有可能会出现增删、也有可能出现重命名（也可认为是一次增删）。

那么专栏中的博客列表也需要跟随变化。

这里我想到的处理办法，是在Series表中存储文件列表及raw_url，在每次同步的时候，获取到最新的文件列表和raw_url，如果发现文件列表不匹配，则根据差异做相应的删除和添加的操作。

这里删除之后，博客相应的评论也会失效，需要谨慎处理。

一方面可以做成软删除，另一方面也可以人为地约束，不随便在Gist中修改文件名称。

如果发现文件名匹配但是raw_url不匹配，说明其内容有更新，正常更新其内容和最后更新时间即可。

总结

总结以上几点，需要做如下的变更：

1. 添加Series表，存储Series名称、文件列表（filename + raw_url + 内部的blog id）
2. Blog表中添加deleted字段，表示软删除，添加series字段，作为一个冗余字段，方便在同步的时候标记删除。
3. 同步Series的时候，对应的Blog的id从原来的gistId变成gistId + filename，原来的单个文件的id还保持不变。
4. 同步Series的时候，根据raw_url是否匹配来决定文件是否有更新。而不是根据整个Gist的更新时间。
5. 同步Series的时候，博客的标题从Gist标题换成内部的第一个 h1 标题，同时在存储内容的时候，需要将这个h1标题去掉。