JADEĀ  Environment Development Ideas

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.

  • Kevin Saul
  • Sep 9 2019
  • Future consideration (Long term)
  • Attach files
  • Kevin Saul commented
    18 Jun 10:14

    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
    05 May 23:47

    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
    05 May 23:13

    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
    October 11, 2019 19:41

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

  • Admin
    Ashley Bass commented
    October 10, 2019 22:19

    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.