Create strongly typed PlanCommand class #6
Conversation
canvas_sdk/commands/plan.py
Outdated
| class PlanCommandAttributes(_BaseCommandAttributes): | ||
| """Attributes speciic to the Plan Command.""" | ||
|
|
||
| narrative: str | None |
There was a problem hiding this comment.
Let's steer right into this question: how do we keep this in sync with the platform? Suppose for example that we decided to add a new field, called timeframe, to the definition of the plan command on the platform, a duration of time within which the plan should be accomplished. How do we protect our customers from being the ones to discover the issues that might be entailed from getting out of sync?
There was a problem hiding this comment.
Idea: integration test? Is there something in home-app exposed via HTTP that returns the command schema? Would it serve our purpose to require that an SDK command class field of a given type exists if and only if it is present in the schema returned in the home-app integration test?
There was a problem hiding this comment.
i think there is an endpoint exactly like that in home-app, i'll dig it up and make an integration test. we could also have a test that runs on a cron and checks daily or something. great idea to call this out
There was a problem hiding this comment.
I like where this is headed. I think we should decide on what the result of the manipulation of one of these command objects should be. I think we want to return an effect to home-app. Does the effect just present to home-app a command state, which home-app then takes and updates the current state accordingly? Would you manipulate many fields in a here, and then call like plan_command.effect() to get the ModifyCommandEffect with appropriate attributes set?
Note: I don't think we have to make this decision before this can be merged.
canvas_sdk/commands/base.py
Outdated
| return {"command_uuid": self.command_uuid, "user_id": self.user_id, "commit": True} | ||
|
|
||
| def enter_in_error(self) -> dict: | ||
| """Enter in error the command.""" |
There was a problem hiding this comment.
Phrasing suggestion:
| """Enter in error the command.""" | |
| """Mark the command as entered-in-error.""" |
|
@aduane ya i've been bouncing a bunch of ideas like that around too as i'm doing this work. i think we just get this initial version in and then make those decisions once grpc is further along! i kinda just threw those straw-man methods in there as placeholders. i'll leave a comment so that's explicit ! |
This PR creates the first iteration of our strongly typed command classes, starting with the PlanCommand. There is a
_BaseCommandwhich handles command-agnostic information, like note_id, user_id, command_uuid, etc. ThePlanCommandclass inherits from _Base and includes anything plan-specific, like narrative.some notes: