新应用发布能否不带设计器数据

一、
在发布一个新应用的时候，设计器的数据会被全部带入，
新用户使用的时候还要先清除这些数据，现在有一百多张表，每次发布都去删除一次太麻烦了，

虽然也做了一个集中的按扭一键删除，但表在不断更新也是一件非常麻烦的事

二、
导入活字格文件的时候，数据也是被导入的，是不是可以只导入空的表呢

三、
有个别的表，如数据字典类型的，系统表，

在发布的时候可i不可以对指定表进行全覆盖

目前覆盖发布是将所有的表都覆盖了，半覆盖对于已存的表是不能选择保留数据的

四、全覆盖和半覆盖的选择，设计的非常没有安全感
1、全覆盖我认为是很少去用的，或者说用的时候肯定是先有导入数据的，所以这个功能应当低调一点，属于高压线，应当保持距离
2、不选择覆盖虽然有必要，但我个人觉得默认为半覆盖的更好，或者说可以选默认更好，因为数据库有更新了，如果不覆盖页面就会出错，这样的发布需求应该较少

感谢您的反馈，这几个需求就合起来给大佬记个需求吧，需求编号是40563
后边会有专门的同事来对这些需求进行评估哈

王总，收到你的反馈了。
首先，必须先感谢一下大佬的反馈，希望我们一直这样直接的沟通，嘿嘿~·
然后，我得给大佬“狡辩”一下，我们对发布这边的想法：
首先，我们更推荐大家的项目使用外联库（Sqlserver，MySQL这些），此时您的这些需求，我们更加推荐大家找靠谱的工具或者SQL语句自己搞，这个更加把稳
关于内置数据库
1.关于数据在发布前清理
a)这个确实难受，正如您说的字典表不清理数据，其他表可能要清理
b)如果是获取到设计器的正式数据，也不能清理
c)只有在开发时测试的数据，才清理
简单点说，清理数据是比较危险的操作，使用频率不高，功能不敢做的过于简单明显。
2.关于覆盖数据库
说实话半覆盖全覆盖都挺危险的，半覆盖危险系数更低，所以我们的做法的是，必须先选覆盖数据，再选半覆盖全覆盖

简单点说，复杂项目数据库最好是选择自己能完全控制的外联数据库，我们对内置数据库的想法是功能可以有，但是不能简单明显。所以是目前的设计

您的这几个需求，我似乎看懂了，又没太看懂。您能总结一下你的需求吗？

Simon.hu 发表于 2023-12-27 09:40
王总，收到你的反馈了。
首先，必须先感谢一下大佬的反馈，希望我们一直这样直接的沟通，嘿嘿~·
然后， ...

感谢领导的回复
这个贴子已经过去两年多了，可能您太忙了不太能关注到也能理解，毕竟微信加了也没空回我一句的。
借这个贴子想问一下领导，
能为格友们解决问题并得到最佳回复的是好同志，有奖领，这个是肯定的
那么像我这种需求提的多的是算好同志还是坏同志？
如果说是坏同志吧其实也能理解，一天屁事多这需求那需求的，烦人
但我每次提需求的时候我都很认真，认真的我觉得我是一个好同志，
哎 好不好领导说了算  要是提出的需求合理并被官方吸收能有一个小红花就好了

关于这个覆盖问题之前确实挺重要
现在我都转成了外联库好多了  虽然设计器直联生产库但是先这样吧，没空处理这个问题

如果有新格友看到这个贴子下面这句话很重要！！！



就我之前提出的问题主要是内置库的问题

默认值是个大问题，发布的时候一不小心就点点点就完蛋了

现在有事忙，先回这些了  

隔壁老王 发表于 2023-12-27 10:56
感谢领导的回复
这个贴子已经过去两年多了，可能您太忙了不太能关注到也能理解，毕竟微信加了也没空 ...

王总，（别这样，我就一个打工的）
咱活字格不可能嫌弃大家发表观点的，再说您要不是真的喜欢产品想让产品更好，谁没事打这么多字，手估计都累了；随时欢迎您和其他所有格友提需求，不然活字格怎么变成大家的活字格呢？

您截图的这个功能，其实默认是为了方便，因为当用户勾选了【覆盖服务器数据库】，那肯定说明这会儿你需要覆盖数据库了，那要么就是全覆盖要么就是半覆盖。
另外，一直保持这样主要是担心，换了位置或者默认选中，更容易让老用户掉坑里