Why can't some schema types be exported individually from packages like you can with source code and client code schemas? E.g. data bindings can't be individually exported from a package to apply them quickly to other environments, and instead you either need to export the entire package/app that include them, or use some workaround like creating a new temporary package, moving the data binding into it, and then exporting that. It would make life simpler if these schemas could all be exported and imported individually for things like applying hotfixes and synchronising environments. The schemas wouldn't even need to be automatically installed, just added to the package with the status symbol to indicate that the data/SQL script etc needed to be installed.
Like
Hi Harvey,
Data binding schemas are not self-contained like source code/client module schemas, they're pointers to specific DB rows plus their relational dependencies, so a lone export risks missing foreign keys or breaking install order. Full package export sidesteps that by keeping the whole dependency graph intact.
Prabhath Surya,
That's true of C# code schemas and client schemas too, which can refer to other C# code and objects, and something which Creatio as a platform is already capable of handling and informing the user of any issues about once the schema is imported, plus with database referential integrity protections in place as a backstop. This doesn't seem like a real issue, certainly not one to reduce the functionality that is useful for developers.
Hello.
The distinction you have noticed comes down to how these schema types are structured internally.
Source code schemas and Freedom UI, client schemas, are stored as discrete metadata objects. Each one has its own unique identifier, its own file within the package structure, and its own entry in the version control log. This one-to-one structure is what allows the platform to export and import them individually.
Data bindings and SQL scripts do not share this same structure. Data content is stored as rows across various application tables, such as lookups, system settings, and translations, linked to a package only through tagging tables, and often dependent on related records in other tables through master-detail relationships or foreign keys. SQL scripts, in turn, are stored as an ordered batch, with installation status tracked at the package level rather than per individual script. Neither of these has a native, single-object identity in the way source code and client schemas do, so the platform has no built-in mechanism to export just one data binding or script while guaranteeing that its dependencies are included alongside it.
This is why the current workaround, moving the specific item into a temporary package and exporting that package instead, is effectively the only way to give it the package-level identity required for individual export.
Best regards,
Antonii
Antonii Viazovskyi,
Thanks Antonii, but if that's the case, how come when working in file system mode, the Data and SqlScripts directories can be so self-contained? And why couldn't they be treated as similarly self-contained for the purpose of exporting & reimporting? Potentially with warning messages if there are unmet dependencies for SQL Scripts.
It seems like Data schemas (which are just a copy of the actual data in the database to be used for transferring to other environments) should be the simplest to be able to export & import, since the database can handle much of the referential integrity issues of related data trying to be installed when the referred record(s) do not exist already being done by the database and reported by the config section in Creatio.
Anyway, I guess it sounds like things aren't going to change, and so we're left in a situation where we either need to copy data between environments using SQL directly against the database or use the workaround, potentially having to create new packages directly in Prod for the purposes of moving some data back down into lower envs; neither of which is appealing.