How come there is no string replace function?

[samer1977]

Hello,

I was wondering why there is no string replace function as part of the functions provided by the modify-overwrite-beta transformation but there is function for substring? was the replace function left in purpose ? Any plans for new release in the future that includes new functions and more transformation options?

[bobeal]

Saw an old PR to add this function: #1030 but it seems it has never been reviewed and merged. Also found a fork of the project where it has been implemented (frox-ag@9e3469d).

Not sure the project is still actively maintained here...

[ncautotest]

it makes little sense modifying and polluting the core library to add your own transformers; just implement your tranformers following the same logic as https://github.com/bazaarvoice/jolt/blob/master/jolt-core/src/main/java/com/bazaarvoice/jolt/Modifier.java

half of the issues in this repo and a good deal of pull requests could/should be handled with custom client-side transformers

[samer1977]

@ncautotest ,

First of all "replace" is such a core function. Show me a string library without replace function. This is not even asking for Regex replace, just literal string replace and by the way your competitor JSLT has string replace function.

Second, Sometimes you are not using code directly and instead you are going through some app\system that provides out of the box jolt transformation capabilities and you only have to provide the spec. For example a lot of people are using Jolt through Apache Nifi and Im glad Nifi has added processors for Jslt in case god forbid someone wants to easily do string replace in json. Unless you are asking people to develop their own custom Nifi jolt processor just to introduce a function which I dont plan to do to over complicate my deployment and upgrade process.

Third, I dont understand what is the deal with coming up with new release that includes enhancements such as adding more functions or spec operation. Is not this how software grows and becomes better. Maybe I'm missing something with Github but its not the first time where I notice repository owners and contributors are hesitant to make any changes or new releases and the code sets there untouched for years where people start asking if this project is being maintained or abandoned. This is code for heaven sake not the 10 commandments.

[ncautotest]

@samer1977: what should or should not go into core is something that project developers are supposed to decide based on user input, and judging by the number of unsolved issues the devs are not currently putting a great deal of effort into it; as a user I'm in the same position as you, and simply making people aware that instead of requesting and waiting until specific transforms make it into core (which could be never) you can take matters into your own hands and add your own predicates that implement absolutely any kind of transformations in a clean way that is decoupled from core..

there is a potential gotcha to be aware of, and it's the fact that com.bazaarvoice.jolt.modifier.function.Function is marked as @Deprecated with no replacement yet in sight...

[samer1977]

@ncautotest ,
I would recommend you look into JSLT as well as both Jolt and JSLT can supplement each other. I can see stuff where jolt can be easier where others jslt can be winner specially when you are looking to do recursive transformation. JSLT has the same problem as Jolt code. Both are owned by teams who are not motivated to make any changes\fixing bugs anytime soon. In my opinion someone needs to come up with something new with long term commitment and dedication and ditch both Jotl and JSLT altogether. Maybe I will do that. stay tuned :)

[ncautotest]

@samer1977: thanks for sharing the JSLT thing! indeed, only a small part of projects get enough traction, manage to win wide adoption and stay alive and updated (at least for a while), while most others sooner or later get abandoned

a good deal of github projects appear as someone's quick fix for a problem, and then authors decide to open source the code.. but overall, long term, there might be better approaches to solve the original problem, including avoiding the use case altogether (if possible); with time, contexts keep changing and that's unavoidable

^{long term it might be less technical debt to generate raw and dirty low-level java jackson code (or whatever other language) given example inputs and outputs using whatever generic technology is available at the moment (including hand-made code) rather than investing and getting locked into specific libraries for each narrow use case; fasterxml jackson already has JsonPointer — in an ideal world I would like to see this be easily doable with jackson alone, and (wishful thinking) the jolt guys would have implemented their solution as a pull request to jackson, rather than reinventing the wheel from scratch}