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

User-defined functions #29

Open
Albibek opened this issue Jan 25, 2018 · 12 comments
Open

User-defined functions #29

Albibek opened this issue Jan 25, 2018 · 12 comments

Comments

@Albibek
Copy link

Albibek commented Jan 25, 2018

Could be great if one could extend default function list with their own functions.

@shravanshetty1
Copy link

https://github.com/jmespath/jmespath.py, already supports user defined functions - anyway it can be supported in this repo as well?

@mtdowling
Copy link

mtdowling commented Apr 9, 2020

What's the use case for user-defined functions? The most important design decision of JMESPath is that all changes start with the spec and that it's language-agnostic. User defined functions deviate from both of these benefits.

@shravanshetty1
Copy link

There can be usecases where we need regex, client should allow the user to extend JMESpath if they wish. Also if its against design decision why is part of some of the clients such as the python client.

@jamesls
Copy link
Member

jamesls commented Apr 9, 2020

I've seen two benefits:

  • You're not using JMESPath for a language agnostic purpose, i.e writing some tool/CLI that uses JMESPath for something (maybe a config or something it exposes). In other words you don't need the language-agnostic part of jmespath.
  • You need functionality that likely will never be added to the JMESPath spec, Regex being a common one.

@shravanshetty1
Copy link

I've seen two benefits:

  • You're not using JMESPath for a language agnostic purpose, i.e writing some tool/CLI that uses JMESPath for something (maybe a config or something it exposes). In other words you don't need the language-agnostic part of jmespath.
  • You need functionality that likely will never be added to the JMESPath spec, Regex being a common one.

Exactly,
Hence we should allow the client to be extended to support user defined functions. The choice is simply left to the user.
Please share your thoughts on if we would be open to such a change in this client?

@cokefd
Copy link

cokefd commented Jan 28, 2021

Regex is a use case that we are after as well.
Is there any way to easily incorporate it?

@JimBugwadia
Copy link

@mtdowling are you open to taking a PR to make it possible to add a custom function? Here is a test case for what I had in mind:

func TestCustomFunction(t *testing.T) {
	assert := assert.New(t)
	data := make(map[string]interface{})
	data["foo"] = "BAR"
	precompiled, err := Compile("to_lower(foo)")
	precompiled.Register(&FunctionEntry{
		Name: "to_lower",
		Arguments: []ArgSpec{
			{Types: []JpType{JpString}},
		},
		Handler: func (arguments []interface{}) (interface{}, error) {
			s := arguments[0].(string)
			return strings.ToLower(s), nil
		},
	})

	assert.Nil(err)
	result, err := precompiled.Search(data)
	assert.Nil(err)
	assert.Equal("bar", result)
}

@JimBugwadia
Copy link

For others who may need this, here is my fork with the custom function support: https://github.com/kyverno/go-jmespath/.

@ghost
Copy link

ghost commented Feb 14, 2022

Gotta say, this one baffled me, why we couldn't simply add a compare date function for ISO 8601 formatted strings due to the spec stating that > < etc are numerical only. This really limits our choices and forces us to do one of:

  • Add data to our schema in the right format, incurring additional marshaling and corrections on both ends
  • Look for some way to add a function, i.e. forking the project then having to maintain a fork
  • Moving to a different query language... we consider the sunk costs high
  • Using a different implementation (not really an option in go at the moment)
  • Using someone else's fork (thank you @JimBugwadia)

You can guess which option we chose.

@springcomp
Copy link

For others who may need this, here is my fork with the custom function support: https://github.com/kyverno/go-jmespath/.

@JimBugwadia we at JMESPath Community would like to do just that: create a community around the language. To this end, we will need official maintainers of the various implementations. Would you like to take over the latest version and become official maintainer for the Go implementation? This version has most bug fixes from issues here and is up to standards with our spec. It "only" lacks third-party functions 😉

@JimBugwadia
Copy link

Hi @springcomp I discussed this with my colleagues @eddycharly @realshuting @chipzoller and we are open to becoming the official maintainers of the Go implementation. @eddycharly has already created a draft PR for the custom functions support.

@springcomp
Copy link

Hi @springcomp I discussed this with my colleagues @eddycharly @realshuting @chipzoller and we are open to becoming the official maintainers of the Go implementation. @eddycharly has already created a draft PR for the custom functions support.

Awesome, please, let me welcome you to JMESPath Community and give you access rights to the repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants