You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Workflow Nodes producing a DataFrame, it would be very helpful to have a set of "advanced" controls whereby the user can have calls to repartition/coalesce, persist(StorageLevel) or unpersist made as a part of the execute invocation. The default behavior would be to not call any of these methods (and only call them when explicitly requested).
Ideally, these controls would be separated from the normal parameters in the front end, residing in (perhaps) a separate tab between "Parameters" and "Ports". However, a more minimalist approach would be to append them to the existing parameters.
Implementation Considerations
Something to consider is to do it with a mix-in trait, so that existing nodes and SDK users could enable the capability selectively (maybe it doesn't make sense in some cases). It also gets rid of the need to special-case handling the DataFrame from other DOperables. This means explicit passing of the DataFrame to some function provided by the mix-in, a step that some may find objectionable. IMO I think it's fine.
For Workflow Nodes producing a
DataFrame
, it would be very helpful to have a set of "advanced" controls whereby the user can have calls torepartition
/coalesce
,persist(StorageLevel)
orunpersist
made as a part of theexecute
invocation. The default behavior would be to not call any of these methods (and only call them when explicitly requested).Ideally, these controls would be separated from the normal parameters in the front end, residing in (perhaps) a separate tab between "Parameters" and "Ports". However, a more minimalist approach would be to append them to the existing parameters.
Implementation Considerations
Something to consider is to do it with a mix-in trait, so that existing nodes and SDK users could enable the capability selectively (maybe it doesn't make sense in some cases). It also gets rid of the need to special-case handling the
DataFrame
from otherDOperable
s. This means explicit passing of the DataFrame to some function provided by the mix-in, a step that some may find objectionable. IMO I think it's fine.cc: @bguseman
The text was updated successfully, but these errors were encountered: