赛事代码管理相关问题

[FranGuam]

这个issue汇总在队式代码测试过程中遇到的bug和体验不好的点

所有人在不重复的前提下都可以追加问题，负责解决这些问题的PR请引用这个issue

[FranGuam]

@BlitherBoom812 新开了一个issue，可以在这边提，这样分类清晰一些 =》

[FranGuam]

• 数据库contest_code表采取同一队只存一个条目的策略，从code1到code6存储多列，难以应对可能的code数量变化，考虑改成code + num的记录形式，可拓展性更好
• contest_code的文件路径使用绝对路径完整记录，实际可以只记录code_id拼出路径，动态性更好

[BlitherBoom812]

神了

• 代码提交窗口的编译按钮不太显眼，在右下角。感觉可以放在标题下面，或者放在表格上面，一眼就能看到。
• 代码提交窗口只有一个编译状态，却有5个编译信息，应该要么都是1个，要么都是5个。

[BlitherBoom812]

• 数据库contest_code表采取同一队只存一个条目的策略，从code1到code6存储多列，难以应对可能的code数量变化，考虑改成code + num的记录形式，可拓展性更好
• contest_code的文件路径使用绝对路径完整记录，实际可以只记录code_id拼出路径，动态性更好

对于第二点，如果以后路径的接口还要修改，在现有条件下只需要修改前端（前端指定 cos 路径并上传代码，前端记录上传的绝对路径）。仅记录 code_id 的情况下需要同时修改前端和后端（前端指定 cos 路径并上传代码，后端解析上传的绝对路径），耦合度上升了，感觉保留路径更好。或者上传代码和路径管理全部移到后端来做，也可减小耦合。

[FranGuam]

• 数据库contest_code表采取同一队只存一个条目的策略，从code1到code6存储多列，难以应对可能的code数量变化，考虑改成code + num的记录形式，可拓展性更好
• contest_code的文件路径使用绝对路径完整记录，实际可以只记录code_id拼出路径，动态性更好

对于第二点，如果以后路径的接口还要修改，在现有条件下只需要修改前端（前端指定 cos 路径并上传代码，前端记录上传的绝对路径）。仅记录 code_id 的情况下需要同时修改前端和后端（前端指定 cos 路径并上传代码，后端解析上传的绝对路径），耦合度上升了，感觉保留路径更好。或者上传代码和路径管理全部移到后端来做，也可减小耦合。

你说得有道理，耦合度的确上升了。不过耦合度的上升可以通过统一规范解决，问题在于如果cos储存文件结构变了，数据库里的绝对路径很难调整，这是我担心的地方。如果上传代码直接交给后端倒也是不错的方案，我支持。

[BlitherBoom812]

• 数据库contest_code表采取同一队只存一个条目的策略，从code1到code6存储多列，难以应对可能的code数量变化，考虑改成code + num的记录形式，可拓展性更好
• contest_code的文件路径使用绝对路径完整记录，实际可以只记录code_id拼出路径，动态性更好

对于第二点，如果以后路径的接口还要修改，在现有条件下只需要修改前端（前端指定 cos 路径并上传代码，前端记录上传的绝对路径）。仅记录 code_id 的情况下需要同时修改前端和后端（前端指定 cos 路径并上传代码，后端解析上传的绝对路径），耦合度上升了，感觉保留路径更好。或者上传代码和路径管理全部移到后端来做，也可减小耦合。

你说得有道理，耦合度的确上升了。不过耦合度的上升可以通过统一规范解决，问题在于如果cos储存文件结构变了，数据库里的绝对路径很难调整，这是我担心的地方。如果上传代码直接交给后端倒也是不错的方案，我支持。

有道理，这样数据库确实减少了调整负担。主要在于cos的文件结构可以批量修改，而hasura大概只能跑几千条脚本一个个改，成本太高。 cos 也是要手改的，也挺麻烦。这样看全部移到后端可能是最好的做法了，后端可以定义一个 get_code_path 路径生成函数，无论是上传还是下载都用同一个路径函数。

[xiangmy21]

Bug Report:

• 上传按钮无法上传代码，问题在于前端请求是形如 /static/THUAI6/code/7a3af771-ca71-4f7d-9813-13a1d5b364b8/player1.py 的格式，而后端路由是 static/code 开头，需要修改后端路由为约定格式。 @zou-y-t