kz930 commented on PR #8506: URL: https://github.com/apache/texera/pull/8506#issuecomment-5735649075
All six are addressed, in two PRs. The generator now rejects the draws Java rejects, and refuses the bound of zero a reservoir of nothing hands it, with the rejection pinned at a bound where half the draws fall in it. Aggregate wraps an INTEGER sum the way Java ints wrap, sums and averages a TIMESTAMP column through its epoch milliseconds, and spells a boolean in lower case. The hash join computes the rename the way `HashJoinProbeOpExec` computes it rather than asking pandas for a suffix, and puts a declared integer column back after an outer join widens it. The sort now places a null last both ways and a NaN where the key points. The null and NaN cases turned out to be a reading problem rather than an operator one: those operators already answer correctly when handed input that tells the two apart, and what flattened them was reading an Arrow file into numpy dtypes. #8341 reads it into the nullable ones instead. Difference, the hash join and Aggregate each carry your case as a run test now. Four I would push back on. Dummy never overrides `getPhysicalOp`, so it inherits the `LogicalOp` default that throws `NotImplementedError`: it cannot execute at all, and so has no routing to lose. Sleep's delay never reaches the output, so the exported table is the engine's row for row. Sampling is seeded with the worker count by the engine and one process can only state one seed, which the two operators' comments already say. Sorting a string parts only where a character above U+FFFF meets one in U+E000..U+FFFF, since the engine reads UTF-16 code units and pandas reads code points. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
