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

Complete JCF Command File Support

As part of recent work, we needed to decommission an old application, with its initialize/finalize methods in particular referring to redundant code.

Previously, we'd have just deleted the initialize/finalize methods via a JCF command, but there's now been some validation introduced which prevents doing that when they're referenced by an application.

Okay, so we'll delete the application as well then (that's good, we don't like clutter anyways). As all our changes are deployed incrementally, we'd do something like this in a JCF command file.

Delete Application <schema>::<application>


However, this JCF command is not supported like others may also have assumed upfront.

The JCF command file support needs to be updated to cover all scenarios where an entity can be deleted or renamed via the IDE. This is particularly relevant in the context of improving source control, for which there needs to be a way of deploying deletes & renames incrementally in a consistent manner.

So far, I've identified the following entities which aren't covered like you might expect by the documented JCF commands:

  • Applications

  • Libraries

  • Exported Package Entities (while a package can be deleted, we can't remove a specific entity from the package via JCF).

  • External Component Libraries (ActiveX & .NET)

  • Exposures (C# & web services)

  • Dynamic Property Clusters

  • Relational Views (ODBC & RPS) (while we can exclude tables/columns, we can't delete/rename RPS mappings via JCF).

  • External Databases

  • HTML Documents

Once completed, it'd be ideal if functionality gaps of this nature were regarded as a fault before/after new schema entities are introduced to ensure complete JCF support is kept up-to-date.

UPDATE (18/06/20):

List of commands specified below in preferred priority order.

Delete Application <schema>::<application>

Rename Application <schema>::<application> <new-name>
Delete Library <schema>::<library>
Rename Package <schema>::<package> <new-name>
Delete [Jade]ExportedType <schema>::<exported-package>::<type>
Delete [Jade]ExportedFeature <schema>::<exported-package>::<type>::<feature>
Delete [Jade]ExposedList <schema>::<exposure-list>
Delete ExternalComponentLibrary <schema>::<activeX-or-dotnet-library-name>
Delete [Jade]HTMLDocument <schema>::<html-document>
Rename [Jade]HTMLDocument <schema>::<html-document> <new-name>
Delete RelationalView <schema>::<relational-view-or-RPS-mappings-name>

Like the Rename Schema command, it would be useful if we also had support for the following rename commands, even though it doesn't appear possible via the IDE (these entities may be renamed via external source control repository) .

Rename Library <schema>::<library> <new-name>

Rename ExternalComponentLibrary <schema>::<activeX-or-dotnet-library-name> <new-name>
Rename RelationalView <schema>::<relational-view-or-RPS-mappings-name> <new-name>

Schema Evolution

For all commands, they should support both latest & current schema versions wherever possible (but we'll happily work with current schema version support initially).

Support for latest schema version is preferred so we can unversion a schema to rollback changes on error should we need to. With that in mind, validation for the deletion of entities in latest schema version should support/understand when we've just deleted a dependent entity rather than throwing an error because it still appears to be in use.

NOTE:

  • I've not covered external databases or dynamic property clusters above, not things I've spent a lot time using, so need to familiarize myself with how they work before suggesting appropriate commands.

  • I've dropped ad-hoc indexes from the initial list above, as I don't believe they're covered by standard schema extract & load functionality.

UPDATE (16/12/20):

I've crossed out the external component libraries above as I've since realized those commands are implied when deleting/renaming the primary proxy class created for those libraries. While the approach is somewhat clunky as you have to delete any sub-classes first, it does work, hence removed them from list above.

  • Kevin Saul
  • Sep 9 2019
  • Future consideration: 2022
  • Attach files
  • Sarah Christie commented
    15 Dec, 2020 12:03pm

    I have also come across the need to delete an application and an exposure list so these commands would be very useful.

  • Kevin Saul commented
    18 Jun, 2020 10:14am

    Hi Hugh,

    Apologies for the delay, I've updated idea to provide more of an outline of commands I believe we're missed/need to provide better coverage for partial/incremental deployments with entities being renamed/deleted.

  • Admin
    Hugh McColl commented
    5 May, 2020 11:47pm

    Hi Kevin,

    It would be useful, if you as the originator of this idea, could update the description with a priority assigned to each of the entity types. Alternatively you could provide a priority ordered list in a comment. That would help us to prioritize an incremental program of work that provided support in tranches.

  • Kevin Saul commented
    5 May, 2020 11:13pm

    Can some of this be progressed in an upcoming release? It's understandable that it can't all be done at the same time, but it'd be good to understand what can/is going to be progressed in the short term. Would it be more manageable if this were split with a new JEDI for each entity type, so they can be allocated to upcoming / future releases?

  • Thaban Segaran commented
    11 Oct, 2019 07:41pm

    The RPS ability to rename/add/delete fields is a must for us.

  • Ashley Bass commented
    10 Oct, 2019 10:19pm

    We're going investigate this and have some questions about priority across our customer base, please respond to the team's questions with your feedback.