Skip to content

refactor(isthmus): strptime function mapping#701

Open
bestbeforetoday wants to merge 2 commits intosubstrait-io:mainfrom
bestbeforetoday:strptime
Open

refactor(isthmus): strptime function mapping#701
bestbeforetoday wants to merge 2 commits intosubstrait-io:mainfrom
bestbeforetoday:strptime

Conversation

@bestbeforetoday
Copy link
Member

Avoid code duplication. Also test operator name and operands explicitly instead of relying on Calcite's toString implementation, which might change over time.

@bestbeforetoday bestbeforetoday changed the title chore(isthmus): refactor strptime function mapping refactor:(isthmus): strptime function mapping Feb 10, 2026
@github-actions
Copy link

ACTION NEEDED

Substrait follows the Conventional Commits
specification
for
release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

@bestbeforetoday bestbeforetoday changed the title refactor:(isthmus): strptime function mapping refactor(isthmus): strptime function mapping Feb 10, 2026
@bestbeforetoday bestbeforetoday marked this pull request as ready for review February 10, 2026 14:18
@nielspardon
Copy link
Member

Also test operator name and operands explicitly instead of relying on Calcite's toString implementation, which might change over time.

I recall that in the past when I added unit tests that there was a preference to rely on Calcite's explain() / toString() implementation for readability of the tests. I guess we should get some clarity on that. Otherwise I'm fine.

Avoid code duplication. Also test operator name and operands explicitly
instead of relying on Calcite's toString implementation, which might
change over time.

Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
Revert to comparison with the Calcite call's toString output instead of
using APIs to explicitly access required values.

Signed-off-by: Mark S. Lewis <Mark.S.Lewis@outlook.com>
@bestbeforetoday
Copy link
Member Author

I generally avoid using toString since the Javadoc for Object.toString has this API note (my emphasis):

In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read. It is recommended that all subclasses override this method. The string output is not necessarily stable over time or across JVM invocations.

I don't see anything in the Calcite Javadoc that confirms the toString format or that it is stable across releases.

For now I have just reverted to using toString. It can be revisited later if it ever breaks.

* @param calciteOperator the Calcite operator to map from (e.g., SqlLibraryOperators.PARSE_DATE)
* @param functions the list of all available scalar function variants
*/
protected AbstractStrptimeFunctionMapper(
Copy link
Member

Choose a reason for hiding this comment

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

if you want to have even more reuse then PositionFunctionMapper also just swaps the position of the first two arguments of its function call

Copy link
Member Author

@bestbeforetoday bestbeforetoday Feb 13, 2026

Choose a reason for hiding this comment

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

This refactor consolidates a family of closely related date/time parsing functions that require the same argument mapping and differ only by the type they return. POSITION deals with string searching so, while it also requires the same argument mapping, the relationship is not obvious and could be confusing. I would prefer to keep this PR focused on removing duplication in the closely related date/time parsing functions.

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.

2 participants