青岛大学OJ总结

先总结一下昨天在服务器端搭建这个平台出了啥子问题

疯狂报错——

Version in “./docker-compose.yml” is unsupported. You might be seeing
this error because you’re using the wrong Compose file version. Either
specify a version of “2” (or “2.0”) and place your service definitions
under the services key, or omit the version key and place your
service definitions at the root of the file to use version 1. For more
on the Compose file format versions, see
https://docs.docker.com/compose/compose-file/

后来查了一篇博客，说是因为操作系统的问题

事实证明，这篇博客有点坑，可能试用它不适用我，正确的做法应该是——

好的，那下面进入正题——

从全局上看：

首先用观察法，整个oj分前端后端

1. 前端
   前端在青岛大学的github网站里——OnlineJudgeFE，里面的文件很清楚，是用js搭的，但很疑惑的是，这个文件夹并没有出现在所下载的这个本地OnlineJudge里面。难道是用某种方式相连？

   那么就带着这个疑问去看文件——
   首先是搜js文件，发现没有专门的网页代码，然后甚至没有专门的文件夹，那就很明白了，一定是存在获取github中前端的这个网址的文件——
   果然啦， Dockerfile中有一句话
   

再回到这个项目的dockerfile部分，第一行：

FROM python:3.7-alpine3.9

表明了基础镜像是,python3.7和alpine3.9——alpine是一个完整的操作系统
然后文件里面的这段代码值得认真的分析一波：

RUN apk add --update --no-cache：更新且不采取缓存模式（缓存可能占用许多不必要的内存）

整体的意思是：
构建依赖关系为平台构建本机拓展。构建完成后，不需要它们。因此，应该在作业完成后删除构建依赖项

而所需要为项目构建的环境，如图中代码所写的，都在一个叫deploy的文件的requirement.txt当中，其中都是开发这个项目所需要添加的库

看到这儿，我突然有点真正明白了docker的作用：

对比与之前的机场调度算法，同样是需要配置环境，机场项目中虽然也有requirement.txt，但却需要手动将sudo install写入命令行，而在oj的这个项目里，直接可以把它封装进dockerfile中去，不仅保证了准确性，而且起到了 隔绝封装的作用

我对dockerfile内容的解析：

2. 后端
   在项目的一个“data”文件夹中有一个“backend”文件夹，这就是放了后端的东西的文件夹
   里面有一个专门的日志文件（而且是需要管理员权限才能打开的），因为没接触过后端，所以自己去搜了这方面的东西——

   后端系统往往运行在自己的服务器上且服务一般不会随便中断。那么如何监控我们的系统就变得尤为重要，一般而言我们会对系统可能存在的问题进行分类，以便采取不同的应对策略

   所以正是由于重要，所以才给他加了权限
   文件夹中还有一个配置文件，里面的有一个——
   
   查了半天也不大晓得为啥放个key文件在这儿，和苹果有啥关系？先把这个问题遗留至此

   后端由于技术知识限制，只看了这么多qwq

3. 我的part——problems文件
   这是文件的概览——
   
   views文件夹：
   众所周知 views文件里面基本是编写web应用视图，然后点进去，发现编写的都是有关题目的一些类，将其作为父类，使其能在同一个文件夹下的其他py文件中被继承，在其他的两个文件夹的py文件中被调用，父类有：

• 题目tag的添加与筛选（包括难度筛选等）

• 题目的查询
  见下图
  
  url文件夹：
  这里面的文件就很清楚明白了，调用views中生成的内置函数，然后生成网页
  
  只剩下migrations文件：

  migrations，顾名思义迁移、迁徙

  在Django应用中，migrations是一系列文件，位于Django应用的migrations目录下，用以存储Django应用中的model类的变化。
  每次在Django应用中对model类的修改，都会对应一个migration文件

  那么就先来说一下models.py文件是个何方神圣——
  
  点进去发现都是一些字段，疯狂调用models.TextField()函数或者是 models.BooleanField()函数，这两个函数都是对于字段的处理，so，这个models.py文件相当于一个单个的数据库表，每个属性也是这个表中的一个字段，属性名就是字段名

  这个代码里还定义了一个meta类，更加印证了这种说法——内部类Meta可给数据模型类增加扩展属性
  
  上面的引用部分有一句话——

  每次在Django应用中对model类的修改，都会对应一个migration文件

  所以说这些文件应该都是修改了model的参数之后造成的重复

  那么剩下的这些文件每个就都很清楚了（看名字就晓得是干啥的）～

  分析就大概这么多，一些具体的运行机制还有待深究～