The JADE 2022 release meets tomorrow’s business demands.
HistoricalComments
John Richards 30/04/2018 9:46:32 AM
We believe this to be potentially dangerous and that moving classes from one mapfile to another is a DBA function not a developer function. John Richards - JADE Development Manager FileVision UK Ltd 6/10/2017 3:34:32 AM Yeah I know, this NFS is suggesting eliminating that step - with the JCF it means you can't just load the latest schemas into a customer's database, so you have to be aware of any JCF that need loading between their current version and the latest version. Blake De?Ath 5/10/2017 10:12:58 AM In case you aren't aware of it, this can be done as a JCF https://www.jadeworld.com/docs/jade-70/Default.htm#resources/devref/chapter_14_-_database_reorganization/using_jcf_commands_to_remap_classes_and_move_class_instances.htm |
Changed status to "needs review" per the request to reopen it for further consideration.
Can this please be re-opened on the basis that moving classes from one map-file to another is a developer function.
Currently, manipulating map files using a JCF is also limited to the current schema version, whereas we'd ideally be able to create, remap, rename & remove map files in the latest schema version via JCF. By implementing this change, we wouldn't need a remap command anymore, but we should instead have a rename command to avoid unnecessary re-orgs due to what appears to be a move caused when renaming a map file.
This idea supports source control systems, as the most effective approach of deploying changes would be to load all changes into into the latest schema version first with one re-org at the very end, which provides the ability to rollback to the current schema version should anything go wrong beforehand (which we cannot currently do in cases like this).
To mitigate the risk of potentially dangerous class moves unintentionally, automatically moving classes could be made subject to an environment or command line setting.