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

Add time related built in function and cumulative value function #197

Merged
merged 11 commits into from
Dec 9, 2021

Conversation

tiopramayudi
Copy link
Collaborator

@tiopramayudi tiopramayudi commented Nov 23, 2021

What this PR does / why we need it:

In this PR we add several built in functions that can be used as expression in standard transformer spec. Below are the functions:

  • IsWeekend(timestamp interface{}, timezone string) interface{}. Return whether a timestamp fall in weekend or not
  • DayOfWeek(timestamp interface{}, timezone string). Return int day indicate day of the week.
  • ParseTimeStampsWithFormat(timestamp interface{}, timezone, format string) interface{}. Parsing timestamp into specific format
  • CumulativeValue(values interface{}) []float64. Accumulate values based on the index, e.g values [1,2,3] => [1, 1+2, 1+2+3] => [1, 3, 6]
    Which issue(s) this PR fixes:

Fixes #

Does this PR introduce a user-facing change?:

NONE

Checklist

  • Added unit test, integration, and/or e2e tests
  • Tested locally
  • Updated documentation
  • Update Swagger spec if the PR introduce API changes
  • Regenerated Golang and Python client if the PR introduce API changes

- column: day_of_week
expression: DayOfWeek(driver_table.Col('eta'), 'Asia/Jakarta')
- column: pretty_date
expression: ParseTimeStampsWithFormat(driver_table.Col('eta'), 'Asia/Jakarta', '2006-01-02')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think ParseTimeStampsWithFormat as function name is quite long. Wdyt about FormatTimestamp for function name?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aggree, I think FormatTimestamp is better name

Copy link
Contributor

@ariefrahmansyah ariefrahmansyah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm with nit comment

@pradithya
Copy link
Member

What is the usecase of CumulativeValue?

@ariefrahmansyah
Copy link
Contributor

Ready for review @pradithya @tiopramayudi

panic(err)
}

timeLocation, err := LoadLocationCached(fmt.Sprintf("%s", tz))
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happen if tz is:

  • slice with single value
  • slice with multiple values

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it will return error, hence panic because the location is not found

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you think we need to validate the timezone data type here? we expect timezone to be single value to match timestamp

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to be defensive and check the type as well

type LocationCache map[string]*time.Location

var (
locationCache = LocationCache{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we use sync.Map instead? Based on the benchmark (write less, read more) the performance is the best. https://www.fatalerrors.org/a/map-concurrency-performance-and-principle-analysis-of-golang.html

panic(err)
}

timeLocation, err := LoadLocationCached(fmt.Sprintf("%s", tz))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to be defensive and check the type as well

@@ -85,76 +85,14 @@ transformerConfig:
features: # list of features to be retrieved
- name: merchant_t1_discovery:t1_estimate # feature name. make sure to include feature set
valueType: DOUBLE # feature value type
defaultValue: '0' # default value if feature value not exist
defaultValue: "0" # default value if feature value not exist
```

> To learn more about JSON Path syntax, please go to [this link](https://goessner.net/articles/JsonPath/), [this](https://restfulapi.net/json-jsonpath/) or [this](https://support.smartbear.com/alertsite/docs/monitors/api/endpoint/jsonpath.html).

### List of Supported UDFs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not UDF. UDF is User-Defined Function. We should replace the mention of UDF in our document with "expression"

| Time | [IsWeekend](#isweekend) |
| Time | [FormatTimestamp](#formattimestamp) |
| Time | [ParseTimestamp](#parsetimestamp) |
| Time | [ParseDateTime](#parsedatetime) |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also have "statistics"

@pradithya
Copy link
Member

pradithya commented Dec 8, 2021

I love that we started to make better documentation about standard transformer!!

}

location := &time.Location{}
if timezoneVals.Kind() == reflect.Slice {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we move out the validation of timezonevals into separate function, i notice it also be used in ParseDateTime function ?

@tiopramayudi
Copy link
Collaborator Author

LGTM

Copy link
Member

@pradithya pradithya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🥳

@ariefrahmansyah ariefrahmansyah merged commit 85c4cbc into main Dec 9, 2021
@ariefrahmansyah ariefrahmansyah deleted the std-trf-built-in-function branch December 9, 2021 10:05
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

Successfully merging this pull request may close these issues.

3 participants