Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

object matching always has to be the last expression which might affect order #356

Open
samer1977 opened this issue May 28, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@samer1977
Copy link

Hi,

I apologize if I'm coming across as obsessive or OCD because I have been submitting a lot of issues since starting the journey of learning jslt. I guess the better word is excited and I hope this is a good thing. I came across another stackoverflow post where Jslt can easily solve problems where jolt could not ( I guess Im going to make you popular :) ). While going through this exercise it brought up something I was biting my tongue on but I guess I will just say it. The concept of using object matching and wild card as its called in jolt to map unlisted fields is just a powerful thing and saves a lot of time and make the spec much concise and easier to read, however in jslt I noticed the expression *:. is always have to be the last expression, for example in the referenced problem above I could not use *:. at the top to preserve the order as in :

{

   *:.,
  "lineItems":[for(.lineItems) { "id":.id,"attributes":from-json(.attributes) }],

 } 

Even without the coma its not going to work. The only way I got it to work is by having it placed at the end as in:

{


  "lineItems":[for(.lineItems) { "id":.id,"attributes":from-json(.attributes) }],
   *:.

 }

I know in json the order is not a big deal and I could careless but I have seen people asking in post that they want to preserve the order for some reason and it doesnt appear to be a hard fix however this will will make big difference to large number of people.

Not sure why this team is so hesitant in making changes and I thought I heard in one of the reply's that you wont make change unless the topic\idea gain some traction from people. Im not sure what are your plans with this, you probably super busy with other big things and this is not a big deal but if you have plans to grow this and make it used by many people , my advice is that you should not wait for people to ask for changes. I think you should be more proactive with it and release more features and functionalities that answer different programming styles and skill set. Maybe some people are not strong with Regex replacement and would rather use literal replace which meets their needs. Finally I'm fixing to write an article in the Cloudera Community under Apache Nifi about my findings with Jslt. I just happen to be a Nifi Guru there (per my contribution). Dont worry its going to be mostly positive :)

One other note ( I dont want to keep opening issues and this probably not worth the reply) : The functions from-json and to-json seem to be reversed when I read from-json I thought it means reading something from-json and convert to something else, on the other side to-json is when I want to convert something to json format just like the famous toString() , or in Java ArrayList.toArray() , ToInt64 in C#....etc.

Sorry for keeping it long.

S

@larsga
Copy link
Collaborator

larsga commented May 28, 2024

I guess the better word is excited and I hope this is a good thing

I think it's a good thing. You're certainly breathing new life into the project.

for example in the referenced problem above I could not use *:. at the top to preserve the order

Anyone who cares about the order of the keys in JSON is doing it wrong, but you are definitely right that there are people who insist on caring, so you do have a point here.

It would mean adding some extra checks to disallow * : . from being used twice, but, yes, this is a change that could be made, and it would probably make some people happy.

@larsga larsga added the enhancement New feature or request label May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants