add custom field name support (NameFn)

[ashtonian]

I added nameFn function the same way we handle column names and defaulted the behavior to match the current behavior so its not breaking, added tests to verify. This is a reopening of #47. PR is now independent of other prs. Added test coverage, good to go on approval.

Original #18.

[sashahilton00]

Just as a heads up @ashtonian the merge commit on your main repo (#d5fc95e) appears to have broken the NameFn logic that was added - I'd open a PR but having scrolled back through the commits there's been quite a bit of restructuring from the main repo, and I was unable to figure things out to open one.

If you get a chance to take a look it would be much appreciated - I'm hoping to take a stab at adding the table= option for fields to allow querying across tables, though I'd like to start from a clean, up to date version first :)

❯ go test
--- FAIL: TestParse (0.00s)
    --- FAIL: TestParse/support_name_struct_opt (0.00s)
        rql_test.go:1121: filter expr:
            	got: "someName = ?"
            	want "some_name = ?"
    --- FAIL: TestParse/test_nameFn_works (0.00s)
        rql_test.go:1121: filter expr:
            	got: "someName = ?"
            	want "some_name = ?"
FAIL
exit status 1
FAIL	github.com/ashtonian/rql	0.144s

[ashtonian]

Hey @sashahilton00, unfortunately I'm not sure when I will be able to prioritize this. I have some things I'd like to do with this project but currently on a 3 month timeline. May be worthwhile to ignore that branch. My intent was to do some refactors to make the project more flexible but I think the strategy I initially chose is not quite right and there is a more robust/functional approach.

[sashahilton00]

Hi @ashtonian,

Thanks for the heads up. I started looking into how one might handle the nested tables approach, and also concluded that it needed quite a significant refactor due to the way the internal structs are initialised/processed.

In case it's of interest to you or anyone else looking to solve a problem similar to mine - my quick and dirty solution is to run a TypeSense instance, with a thin DSL on top of the search/query filters they provide.

Probably a bit heavy for most use cases, but I was using it already.

Nonetheless I'll keep an eye out on this library and your progress - I'm surprised there isn't a more fully fleshed out solution to this requirement already available to be honest.