| Conditions | 12 | 
| Total Lines | 79 | 
| Lines | 0 | 
| Ratio | 0 % | 
| Changes | 0 | ||
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
Complex classes like create_request() often do a lot of different things. To break such a class down, we need to identify a cohesive component within that class. A common approach to find such a component is to look for fields/methods that share the same prefixes, or suffixes.
Once you have determined the fields that belong together, you can apply the Extract Class refactoring. If the component makes sense as a sub-class, Extract Subclass is also a candidate, and is often faster.
| 1 | # Licensed to the StackStorm, Inc ('StackStorm') under one or more | 
            ||
| 47 | def create_request(liveaction):  | 
            ||
| 48 | """  | 
            ||
| 49 | Create an action execution.  | 
            ||
| 50 | |||
| 51 | :return: (liveaction, execution)  | 
            ||
| 52 | :rtype: tuple  | 
            ||
| 53 | """  | 
            ||
| 54 | # Use the user context from the parent action execution. Subtasks in a workflow  | 
            ||
| 55 | # action can be invoked by a system user and so we want to use the user context  | 
            ||
| 56 | # from the original workflow action.  | 
            ||
| 57 | parent_context = executions.get_parent_context(liveaction)  | 
            ||
| 58 | if parent_context:  | 
            ||
| 59 |         parent_user = parent_context.get('user', None) | 
            ||
| 60 | if parent_user:  | 
            ||
| 61 | liveaction.context['user'] = parent_user  | 
            ||
| 62 | |||
| 63 | # Validate action.  | 
            ||
| 64 | action_db = action_utils.get_action_by_ref(liveaction.action)  | 
            ||
| 65 | if not action_db:  | 
            ||
| 66 |         raise ValueError('Action "%s" cannot be found.' % liveaction.action) | 
            ||
| 67 | if not action_db.enabled:  | 
            ||
| 68 |         raise ValueError('Unable to execute. Action "%s" is disabled.' % liveaction.action) | 
            ||
| 69 | |||
| 70 | runnertype_db = action_utils.get_runnertype_by_name(action_db.runner_type['name'])  | 
            ||
| 71 | |||
| 72 | if not hasattr(liveaction, 'parameters'):  | 
            ||
| 73 | liveaction.parameters = dict()  | 
            ||
| 74 | |||
| 75 | # Validate action parameters.  | 
            ||
| 76 | schema = util_schema.get_schema_for_action_parameters(action_db)  | 
            ||
| 77 | validator = util_schema.get_validator()  | 
            ||
| 78 | util_schema.validate(liveaction.parameters, schema, validator, use_default=True,  | 
            ||
| 79 | allow_default_none=True)  | 
            ||
| 80 | |||
| 81 | # validate that no immutable params are being overriden. Although possible to  | 
            ||
| 82 | # ignore the override it is safer to inform the user to avoid surprises.  | 
            ||
| 83 | immutables = _get_immutable_params(action_db.parameters)  | 
            ||
| 84 | immutables.extend(_get_immutable_params(runnertype_db.runner_parameters))  | 
            ||
| 85 | overridden_immutables = [p for p in six.iterkeys(liveaction.parameters) if p in immutables]  | 
            ||
| 86 | if len(overridden_immutables) > 0:  | 
            ||
| 87 |         raise ValueError('Override of immutable parameter(s) %s is unsupported.' | 
            ||
| 88 | % str(overridden_immutables))  | 
            ||
| 89 | |||
| 90 | # Set notification settings for action.  | 
            ||
| 91 | # XXX: There are cases when we don't want notifications to be sent for a particular  | 
            ||
| 92 | # execution. So we should look at liveaction.parameters['notify']  | 
            ||
| 93 | # and not set liveaction.notify.  | 
            ||
| 94 | if not _is_notify_empty(action_db.notify):  | 
            ||
| 95 | liveaction.notify = action_db.notify  | 
            ||
| 96 | |||
| 97 | # Write to database and send to message queue.  | 
            ||
| 98 | liveaction.status = action_constants.LIVEACTION_STATUS_REQUESTED  | 
            ||
| 99 | liveaction.start_timestamp = date_utils.get_datetime_utc_now()  | 
            ||
| 100 | |||
| 101 | # Set the "action_is_workflow" attribute  | 
            ||
| 102 | liveaction.action_is_workflow = action_db.is_workflow()  | 
            ||
| 103 | |||
| 104 | # Publish creation after both liveaction and actionexecution are created.  | 
            ||
| 105 | liveaction = LiveAction.add_or_update(liveaction, publish=False)  | 
            ||
| 106 | |||
| 107 | # Get trace_db if it exists. This could throw. If it throws, we have to cleanup  | 
            ||
| 108 | # liveaction object so we don't see things in requested mode.  | 
            ||
| 109 | trace_db = None  | 
            ||
| 110 | try:  | 
            ||
| 111 | _, trace_db = trace_service.get_trace_db_by_live_action(liveaction)  | 
            ||
| 112 | except StackStormDBObjectNotFoundError as e:  | 
            ||
| 113 | _cleanup_liveaction(liveaction)  | 
            ||
| 114 | raise TraceNotFoundException(str(e))  | 
            ||
| 115 | |||
| 116 | execution = executions.create_execution_object(liveaction, publish=False)  | 
            ||
| 117 | |||
| 118 | if trace_db:  | 
            ||
| 119 | trace_service.add_or_update_given_trace_db(  | 
            ||
| 120 | trace_db=trace_db,  | 
            ||
| 121 | action_executions=[  | 
            ||
| 122 | trace_service.get_trace_component_for_action_execution(execution, liveaction)  | 
            ||
| 123 | ])  | 
            ||
| 124 | |||
| 125 | return liveaction, execution  | 
            ||
| 126 | |||
| 235 |