GitHub user sivaguru-rajasekaran added a comment to the discussion: Oracle
Table Input with variables (${LAST_RUN_TS}, ${LAST_RUN_ID}) failing in Apache
Hop
Good question — this is actually the key distinction.
What you’re running into isn’t a limitation of Table Input, it’s when the
values are being resolved.
LAST_RUN_TS and LAST_RUN_ID are being treated as compile-time variables, not
row-level runtime values, which is why they don’t resolve when embedded
directly in the query. JavaScript “works” only because it forces evaluation
earlier — but that’s also why it’s fragile.
Instead of JS substitution, the reliable approach is to pass these as data, not
variables.
Suggested pattern:
Use Get Variables (or a Table Input / Row Generator) to land
LAST_RUN_TS and LAST_RUN_ID as fields in a row
Use Calculator / Select Values to:
enforce correct data types
format timestamp explicitly (no implicit casting)
In Table Input, enable Replace variables in script? = No
Use ? placeholders in the SQL and let the incoming row bind them at runtime
Example:
SELECT ...
FROM ...
WHERE run_ts > ?
AND run_id > ?
As long as the incoming stream has:
column 1 → timestamp
column 2 → number
the engine will bind them correctly at execution time.
The intermittent behavior you’re seeing with JS is due to pipeline streaming —
variable resolution and query execution can happen out of order unless
everything is serialized into the same row flow.
Bottom line:
JS isn’t wrong, but it’s compensating for a timing issue. Treat the values as
row data, not variables, and the problem goes away.
Happy to walk through a concrete example if needed.
GitHub link:
https://github.com/apache/hop/discussions/6250#discussioncomment-15341051
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
