Open slacto opened 8 years ago
burningice2866
commented
8 years ago Consider making sure to deploy your schema changes together with the code. That way new tables or changes are applied to the database the same way as new code is deployed to the website and there won't be any problems.
SQL Source Control from redgate is a great tool for exactly that.
burningice2866
commented
8 years ago Another approach is not to have your Dynamic[Xml|Sql]DataProvider.config in source control. That way C1 will automatically pick up new datatypes after a deployment and add them to the config and create necessary tables at first startup.
This approach requires all types to be static - if you have any Dynamic Types it won't work.
slacto
commented
8 years ago In this case the point of mixing DynamicXmlDataProvider.config and DynamicSqlDataProvider.config is to keep a simple setup and avoid SQL source control by having developer controlled data in XML (in file based source control) and customer controlled data in SQL (without source control).
On some sites is a possibility not to have Dynamic[Xml|Sql]DataProvider.config in source control, but since most of packages from Composite uses dynamic data type it would be best if new interfaces DynamicSqlDataProvider.config automatically creates new tables
When deploying local changes with new static datatypes to production environment it is a problem if parts of the site is on SQL. Then we need to overwrite both DynamicXmlDataProvider.config and DynamicSqlDataProvider.config. New interfaces in DynamicXmlDataProvider.config works fine and creates new xml files but DynamicSqlDataProvider.config does not create new tables. The annoying workaround is to delete the new interfaces from DynamicSqlDataProvider.config so Composite C1 can create the tables and update DynamicSqlDataProvider.config.