JADE Environment Development Ideas

What's new in the upcoming JADE release?

IMPROVED DEVELOPER EFFICIENCY. ENHANCED SECURITY. SMOOTHER INTEGRATION

The JADE 2022 release meets tomorrow’s business demands.


Start your update to JADE's latest release

Allow moving instances between map files as part of schema load

As has been mentioned in other ideas, it's easy to accidentally put classes in the wrong map file. If this isn't noticed before the application is deployed, this results in large amounts of client data in the wrong map file, which is a pain to fix.

It would be nice if we could just load a new schema with the map files corrected and the instances would be moved for us, in the same way that structural changes are made in a reorg.
  • John Munro
  • May 1 2019
  • Future consideration
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
  • Attach files
  • Ashley Bass commented
    May 31, 2019 04:25

    Changed status to "needs review" per the request to reopen it for further consideration.

  • Kevin Saul commented
    May 03, 2019 02:55

    Can this please be re-opened on the basis that moving classes from one map-file to another is a developer function.

    • Developers have to maintain the map file as part of the class definition stored as part of our source code.
    • Deploying changes to existing classes which are managed by a source control system will fail when/if a DBA were to change the map file outside of source control.

    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.

  • +5