问题1：扩展组件中的实体，是否会在主应用程序启动时自动创表?
问题2：主应用程序是否检测拓展组件实体的变化？
问题3：如果既不自动创表也不检测实体变化，只能通过xml文件来控制实体变化和表结构变化吗？
问题4：在问题3的基础上，协作开发有没有方便管理xml文件的办法，防止多人开发造成混乱
你好！
首先，Studio 需要有能生成 Liquibase 脚本的许可。
然后，Studio 可以为扩展组件生成 Liquibase 脚本。需要在扩展组件中定义 DataStore:
这样就可以在 DataStore 上点击右键执行 “Generate Liquibase Changelog” 了。
注：扩展组件的 DataStore 设置保存在
jmix-studio.xml文件中。因此如果有两个开发人员分别使用独立项目和组合项目的方式开发，那么这两人需要分别新建 DataStore，因为独立项目和组合项目的jmix-studio.xml文件位于不同的目录。
因此，你的问题 3 就不存在了。问题 4 也就不存在了。
所以我还是需要手动Generate Liquibase Changelog生成xml文件才行。
那考虑下面的情况，我和同学同时开发该拓展组件，需要同时改动同一个实体，那么我们必须合并代码后再重新生成xml文件才能避免表结构出现问题
另外
reports插件的自动建表功能是如何实现的呢
也是xml控制的吗，我记得xml文件的执行是在liqiubase控制台中执行的（项目启动前任务）
刚好路过看到。
是的，按你说的情况最好是实体定下来再生成脚本。但是我个人感觉这个任务分配有点问题 
同一个实体应该交给一个开发修改。
Reports 插件有 Liquibase 脚本啊，主程序启动的时候就会执行扩展组件中的脚本。如果你用的 Studio 1.5，建议你阅读一下： 最近更新 :: Jmix 文档
Liquibase 中台现在合并到主程序日志了。
2 个赞
人晕了，这个xml我们从一开始就是放弃管理的，直接排除出git，所以经常删库建库，搞到现在也没找到很好的管理办法，太容易出问题了，不过现在分组件开发的话，这个问题确实绕不开了
哈哈，稳住了~
建议实体改动交给专人负责。从工作流程上规避这个问题。
数据模型是业务的核心，大家都随意修改，不是很好的实践。
目前的工作流程是模块分工，实体到接口全包，主要也是因为业务复杂，不同模块简直像一个新应用，目前比较好的解决办法就是再分细一点，模块单人负责，问题就迎刃而解了