关于接口版本管理的问题 about showdoc HOT 12 CLOSED

能否考虑有个总的分类，按照项目版本来划分，每个版本下放置所有的项目，也便于后期统计？

from showdoc.

其实我自己的想法是用多个项目来管理的。我觉得几十个项目 * n 个版本并不算难管理。因为项目列表都有全局搜索功能，都可以很快搜索出项目。项目列表里是可以很多项目的。

from showdoc.

要增加一个版本，把把旧项目复制一份到新项目里，然后新项目修改即可。我觉得这种方式还行吧

from showdoc.

是的 虽然全局搜索是可以搜出来，但是避免不了数据混乱，假设有个目录能管理起来，就比较明朗了，每个版本都有对应的项目内容

from showdoc.

"同名的接口，当点击v1的时候 v1.05的会同步展开"，我再看了这句话，这话不对吧。右侧菜单，在同名的时候才存在此问题。左侧菜单我印象中没问题的。

from showdoc.

我是比较建议用 多项目 来管理版本的 。如果你们的版本实在太多，就放在同一个项目的不同目录也凑合吧。我印象中并不存在你说的bug

from showdoc.

嗯 确实是存在的，触发方式大概是先点开了v1.05的某个接口，再去点击v1.1的同名接口，后续再点开任何接口都会同步先把v1.05的接口打开（因为会比较长，所以需要先折叠后才能看到v1.1想要看的接口），规避方式就是刷新页面后不点v1.05的目录直接去点
v1.1就行了

另外查询接口的话我也大体写了一下
WITH RECURSIVE catalog_cte AS (
-- 基本情况：直接选出parent_cat_id等于444939701的记录
SELECT c.cat_id, c.cat_name, c.item_id, c.s_number, c.addtime, c.parent_cat_id, c.level
FROM catalog c
WHERE c.parent_cat_id = 444938865
UNION ALL
-- 递归情况：选出parent_cat_id等于前一个结果的cat_id的记录
SELECT c.cat_id, c.cat_name, c.item_id, c.s_number, c.addtime, c.parent_cat_id, c.level
FROM catalog c
INNER JOIN catalog_cte cte ON cte.cat_id = c.parent_cat_id
)
-- 查询page表，并关联catalog_cte
SELECT p.page_id,
p.author_uid,
p.author_username,
p.item_id AS page_item_id,
p.cat_id,
p.page_title,
p.page_content,
p.s_number AS page_s_number,
p.addtime AS page_addtime,
p.page_comments,
p.is_del,
p.page_addtime,
p.ext_info,
cte.cat_id AS catalog_cat_id,
cte.cat_name,
cte.item_id AS catalog_item_id,
cte.s_number AS catalog_s_number,
cte.addtime AS catalog_addtime,
cte.parent_cat_id,
cte.level
FROM page p
INNER JOIN catalog_cte cte ON p.cat_id = cte.cat_id
WHERE p.is_del <> 1;

from showdoc.

我这边重现不了你说的问题，实测没问题。我感觉这个可能是历史里遗留下 page_id 和cat_id重复引起。你尝试 复制一份当前项目，然后看一下新项目是否还有问题。如果没问题，以后都在新项目上修改即可。

from showdoc.

复制一份新项目会让id重新增加，应该避免重复问题了

from showdoc.

好的 谢谢作者大大，能不能加个联系方式？或者有没有官方交流群，好像QQ群没什么人回应😂

from showdoc.

from showdoc.

好的再次感谢~

from showdoc.