#1047 Expose AddFunction API for CESQL Parser

[dgeorgievski]

As discussed in #1047 added support for addition of user defined functions.

• AddFunction API
• TCK tests for user defined functions.
• Instructions on using user defined functions in README file.

@Cali0707, waiting on your feedback. The PR has a working version of the implementation, but it might need to be refined especially when it comes to testing,

I've noticed that the test/tck_test.go manages all the testing of SQL expressions and functions. I've also added runtime/functions_resolver_test.go to be able to test the new runtime.AddFunction function. Is that ok?

[Cali0707]

Hey @dgeorgievski at a first look, these changes seem good! My only thought is to maybe not use the tck tests for this, as those tests are meant to test the CESQL spec and are mirrored from the cloudevents spec repo. Since the spec only says An engine SHOULD also allow users to define their custom functions, I think it is better in our case to just have the test cases you added be in their own test file somewhere else.

I'll take a closer look at the implementation next Monday!

[dgeorgievski]

I think it is better in our case to just have the test cases you added be in their own test file somewhere else.

I agree. Let's decide first on the new location of the tests. My first impulse was to place them under runtime/ considering I am testing runtime.AddFunction in the same dir as well.

[Cali0707]

Yeah putting them into runtime sounds reasonable to me!

[dgeorgievski]

• Moved user defined functions tests from sql/v2/test to sql/v2/runtime
• Created runtime_test package to avoid circular import runtime package errors.
• Using the same TCK mechanism for running user defined functions test to simplify the users validation of new functions. For example, if I'd like to test a new function I plan to use in my app, I'd be able to quickly validate it by adding both the function definition and all the required tests cases in these two files without the overhead of creating the required events for testing.
  1. runtime/user_defined_functions_test.go.
  2. runtime/tck/user_defined_functions.yaml`.

Running user defined functions tests

$ go test -v ./runtime
...
--- PASS: Test_functionTable_AddFunction (0.00s)
    --- PASS: Test_functionTable_AddFunction/Add_user_functions_to_global_table (0.00s)
    --- PASS: Test_functionTable_AddFunction/Fail_add_user_functions_to_global_table (0.00s)
...
--- PASS: Test_UserFunctions (0.01s)
    --- PASS: Test_UserFunctions/User_defined_functions (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/KONKAT_(2) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/KONKAT_(3) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/HASPREFIX_(1) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/HASPREFIX_(3) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/HASPREFIX_(5) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/HASPREFIX_(4) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/HASPREFIX_(2) (0.00s)
        --- PASS: Test_UserFunctions/User_defined_functions/KONKAT_(1) (0.00s)
PASS
ok      github.com/cloudevents/sdk-go/sql/v2/runtime    0.022s

[Cali0707]

Just one small question about where files go, otherwise LGTM from me!

[Cali0707]

Since this is in a separate package for import purposes, do you think it would make sense to move it into a new (nested) directory like /runtime/test (which would also then have all the tck files in the same directory)>

[dgeorgievski]

Yes, I believe creating a dedicated test directory would provide more flexibility for future customizations. Will be right back.

[dgeorgievski]

Tests assets moved to runtime/test dir.

[Cali0707]

LGTM from me