Open kbrock opened 2 months ago
update:
think this is still part of discussions
Overall I like the concept, but I think of context as more of the "serializable" part of the workflow, so it feels like the wrong place to put the logger. I think workflow itself feels like the more appropriate place. @agrare @kbrock thoughts?
@Fryguy Yes, @agrare feels the same way as you do.
source.asl
-- source code.Context#state.input
/ Context#input
Context#credentials
(recent change)Context#state_history
Context.logger
but up to you)I was pushing that Workflow
would only be the AST
, but looks like we have linked context
in there. I did try and pull context
out, but it didn't work so well.
Maybe we want a different object to group context
(really only need the current state), credentials
, logger
update:
update:
update:
update:
Other than the logger belonging to Context I think this looks good, I would have thought logger lived with a Workflow
WIP: going to find another home for the logger. Possibly pass in a RuntimeContext, similar to an ImageProcessor context with Context State, credentials, and logger
un-WIP
Logistically, Context#logger
works much better than Workflow#logger
. The latter caused too many extra variables to get passed around, specifically in the Runner
.
Philosophically, I feel the Context
holds all execution and user specific state, while the Workflow
holds no state and is valid across executions. By this definition, the logger belongs with the Context
.
Elephant: Wihle I don't like the fact that Workflow
currently has a reference to Context
, I'm waiting for wait
to settle down before suggesting any further change there.
lib/floe/cli.rb
puts
. Remove all debugging statements.puts
. Remove all debugging statements.puts
. Remove all debugging statements.lib/floe/cli.rb
puts
. Remove all debugging statements.puts
. Remove all debugging statements.puts
. Remove all debugging statements.
Goal
The logging is global to all of floe. This means we do not associate certain logging information with each user/run.
Setting up a per execution log allows us to isolate the log per running instance and display it to the end user.
Implementation
The
Context
is a per execution concept. It contains the user's information (in execution), the user's credentials, and the runtime context. (including credentials in context has conflated the db context and the runtime context)Since we want a per execution logger, I added logger to the
Context
.Alternative
The
Workflow
currently contains the states and the runtimeContext
. The suggestion was to add thelogger
to theWorkflow
. Unfortunately, this does not work because while the various components have access to theContext
, they do not have access to theWorkflow
.So I propose we stay the course and use
Context#logger