String::replace

[Kevin]

Hi All,

As part of the Jade 2016 SP1 release details, the signature for the new String::replace function has been published for the upcoming Jade 2018 release.

The signature of this is:

Code: Select all

replace(target: String; replacement: String; bIgnoreCase: Boolean): String;

However, we've already got an existing String::replace implementation with the following signature:

Code: Select all

replace(target: String; replacement: String): String;

This has approx. 300 references that will need to be changed via our source control procedures (along with associated testing), with all changes being released simultaneously alongside the method signature change. Depending on company policies when it comes to implementing/testing such changes, the time & effort involved could end up making an upgrade to Jade 2018 prohibitively difficult for anyone in a similar boat.

Before submitting anything via JEDI to ask for things that could help us with the migration/upgrade path to Jade 2018 in this regard - I first wanted to raise this here to give others the chance to share how their String::replace methods are defined (I'm assuming we've all got a version of this!), so we can all see which one is most common.

Couple of Jade features that'd be useful to have in general, which would help with this:

• Default parameters. In lieu of method overloading, this would allow the default value of the last parameter to be specified by Jade, so we can utilise the String::replace function upfront.
• Rename Method JCF command. This would allow us to rename our current implementation to something else, along with updating all references simultaneously.

Thoughts?

Cheers,
Kevin

[BeeJay]

Our implementation was an updating method that changed the receiver of the method and returned the number of occurrences it found which needed replacing:

Code: Select all

replaceString( pOldString : String; pNewString : String ) : Integer updating;

Ours is also called 'replaceString', rather than just 'replace', which means we have no conflict when upgrading to Jade 2018. If there was a conflict, I'd probably just rename our existing implementation, removing the need for large amounts of regression testing from changing over to the new Jade logic. This would also fix up all method references automatically in our development environment ready for our next release. Then, we could look at moving to the new version over time, but initially probably only for areas where there are actually performance issues with our existing version, to reduce the testing overhead for any given release.

Cheers,
BeeJay.

[Kevin]

Hi BeeJay,

I think we'd be in favour of renaming our existing implementation to avoid large amounts of regression testing,

However, there's no command documented that'd allow us to do this on deployment.

Are you saying you'd do this manually in each of your production environments? Or is there another way?

Cheers,
Kevin

[BeeJay]

We have no access to any of our production environments, so no we wouldn't be doing this manually in any of them. The deploy of our next release would simply delete the old method, due to it being missing from the schemas, and create the 'new' method. The existing methods which were previously using the old method would also get recompiled by the schema load to reflect the new method name.

I should point out that we always ship full schemas for our 'full releases', not partial schemas like we use for our HotFixes and consolidated patch releases. With the optimisations which were added to Jade some time back, such that schema loads 'do not' recompile or version unchanged methods or classes, shipping full schemas removed a lot of the previous complexity of deploying releases, and ensures we ship everything which is required for the release, without increasing the elapsed time for the deployments to unmanageable levels.

Cheers,
BeeJay.

[ghosttie]

Our is

Code: Select all

replace(pS_LookFor : String; pS_ReplaceWith : String) : String;

I'd be fine with just biting the bullet, deleting our version and fixing all the compile errors.

[JohnP]

Ours is

Code: Select all

replace(scanFor,replaceWith:String):String;

The plan is to rename it to replaceAll before the upgrade, then change replaceAll to call the new method with ignoreCase=false.

[Kevin]

Hi All,

Thanks for the information, it's interesting to note those of us with an existing 'replace' method have used the same signature (perhaps we could live without the case sensitivity option?).

As colleagues have expressed their preference to have the ability to rename methods via JCF, I've now submitted a JEDI for this.

We've been bitten by this type of conflict before during previous upgrades, but as those were major upgrades which were much hands on regardless, someone was available out of hours to manually rename things in production environments at the right time.

But, as upgrades are meant to be simpler going forward, we're hoping we'll be to have these fully automated going forward - Hence we'd prefer the ability to rename methods via JCF when conflicts like this arise.

@BeeJay - We can't ship full schema extracts for a release. Our procedures rely on using patch & partial extracts, in order to support individual changes moving at different paces, where each may or may not make it into our monthly releases.

Cheers,
Kevin

[BeeJay]

@BeeJay - We can't ship full schema extracts for a release. Our procedures are rely on using patch & partial extracts, in order to support individual changes moving at different paces, where each may or may not make it into our monthly releases.

Have you considered using your patch/partial extracts out of your development environment and then loading the result of that into a staging environment at the same level as your production releases. You can then do the full schema extract from that staging environment. That way, you avoid taking changes you don't want to ship whilst also being able to ship a 'full schema' and handle a method rename etc, and avoid the need to construct jcf files to delete stuff that is no longer required?

I'm assuming you don't ship encrypted schemas, like we do for our releases, as that would make it rather difficult for the rename command to 'fix' any calling methods and then recompile them as it doesn't have the source code available to do said recompile in that target system. This means even if the method rename is added, we would still have to ensure we include all calling methods in our patch. That means we'd be no better off than simply using the existing delete method command and then loading a patch which includes the new method and all calling methods because we will have to ship all the calling methods regardless of the command we use.

But it would still definitely be a useful extension to the available jcf commands for sites that don't ship encrypted methods.

Cheers,
BeeJay.

[ghosttie]

@BeeJay - We can't ship full schema extracts for a release. Our procedures rely on using patch & partial extracts, in order to support individual changes moving at different paces, where each may or may not make it into our monthly releases.

Wow that sounds like a support nightmare

[Kevin]

Hi Guys,

Discussing best practices for deployment is a topic all on it's own, so I'm trying to hold back a little ...

We do have procedures for staging/testing our releases, which goes through weeks of regression testing before production. For major projects, we'll sometimes even run things in parallel with production for a while to compare.

Meanwhile, we have a hot fix procedure for resolving critical issues when they arise in production - Fixes which would definitely be overwritten by the next release that's already in the pipeline if we were using full schema deployments.

For this reason, I highly doubt we'd ever switch to deploying full schemas.

I understand why it's being suggested, but it means switching from one extreme to another, which brings with it other changes/limitations to how we can do things that won't work for us. What I believe we all need is something in the middle to gain the best of both worlds. Coincidentally, this is something I'm aspiring to do with my source control project - the build process within which is designed to generate the least number of partial schema files needed to deploy changes, which are split when necessary to accommodate commands that need to be performed between schema loads for complicated deployments (i.e. moving an existing class under a new class).

With regards encryption,

No, we don't ship encrypted schemas (all our production environments are under our control using a development security library).

Presumably though, Jade has some low-level data stored that's used when calling other methods that could be fixed. If there's no method source to update, perhaps nothing needs to be changed (assuming methods are called by reference rather than name).

How does it cope in other scenarios when things need to be recompiled? i.e. adding/removing method re-implementations is a scenario that comes to mind which causes a recompile of existing references.

Cheers,
Kevin