-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement CalcJob
process class
#2389
Implement CalcJob
process class
#2389
Conversation
0bf4e16
to
fa3652c
Compare
fa3652c
to
1d4d305
Compare
5c35c74
to
62638b4
Compare
This commit can be summarized in three steps: * Reimplementation of a job calculation as `Process` called `CalcJob` * Changing job calculation to be purely informational * Remove the old job calculation mechanics and business logic The old way of creating a job calculation, was to subclass the `JobCalculation` class and override the `_use_methods` class method to define the input nodes and the `_prepare_for_submission` to setup the input files for the calculation. The problem was that these methods were implemented on the `Node` class, thus mixing the responsabilities of running and introspecting the results of a completed calculation. Here we define the `CalcJob` class, a subclass of `Process`. This class replaces the old `JobCalculation` and allows a user to defined the inputs and outputs through the `ProcessSpec`, just as they would do for a `WorkChain`. Except, instead of defining an `outline`, one should implement the `prepare_for_submission`, which fulfills the exact same function as before, only it is now a public method of the `CalcJob` process class. Finally, the role of the job calculation state, stored as an attribute with the key `state` on the `CalcJobNode` has changed significantly. The original job calculations had a calculation state that controlled the logic during its lifetime. This was already superceded a long time ago by the process wrapper that now fully governs the progression of the calculation. Despite the calculation state no longer being authoritative during the calculation's lifetime, it was still present. Here we finally fully remove and only leave a stripped down version. The remaining state is stored as an attribute and is a sub state while the `CalcJob` process is in an active state and serves as a more granual state that can be queried for. This is useful, because the process status, which also keeps similar information is human readable and doesn't allow for easy querying.
62638b4
to
72083b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple minor things
SET key = regexp_replace(attribute.key, '^environment_variables', 'custom_environment_variables') | ||
FROM db_dbnode AS node | ||
WHERE | ||
attribute.key like 'environment_variables%' AND |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few notes here
- you should escape the underscore (should be
\_
) - maybe better to do something like
(attribute.key='environment_variables' OR attribute.key like 'environment\_variables.%')
Similar for the others where applicable (where it's a single variable and not a dict/list, you don't need to do like instead, just =)
raise ModificationNotAllowed('invalid link: CalcJobNode has to have state in {}, but is {}'.format( | ||
valid_states, state)) | ||
|
||
def validate_outgoing(self, target, link_type, link_label): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we want to still do some validation depending on the (process_)state? Or it's somewhere else?
The `replace_*link_from` methods where only implemented because they were needed by the old job calculation created. Since that system is now removed, this functionality is no longer needed. Likewise, the methods to remove links, either from the cache or the database were not used nor tested and so they are removed.
When a `Node` instance is sealed, it should be impossible to add links to or from it. To enforce this, the `validate_incoming` and `validate_outgoing` methods are overridden in the `Sealable` mixin that will raise `ModificationNotAllowed` if the node is sealed.
In the pattern operands for the `LIKE` operator, the underscore is a special character that matches any character. If a literal underscore should be matched, it should be escaped by a backslash.
d0b6c67
to
70f5ff6
Compare
Wonderful! |
Fixes #2377, fixed #2280, fixes #2219 and fixed #2381
This commit can be summarized in three steps:
Process
calledCalcJob
The old way of creating a job calculation, was to subclass the
JobCalculation
class and override the_use_methods
class method todefine the input nodes and the
_prepare_for_submission
to setup theinput files for the calculation. The problem was that these methods were
implemented on the
Node
class, thus mixing the responsabilities ofrunning and introspecting the results of a completed calculation.
Here we define the
CalcJob
class, a subclass ofProcess
. This classreplaces the old
JobCalculation
and allows a user to defined theinputs and outputs through the
ProcessSpec
, just as they would do fora
WorkChain
. Except, instead of defining anoutline
, one shouldimplement the
prepare_for_submission
, which fulfills the exact samefunction as before, only it is now a public method of the
CalcJob
process class.
Finally, the role of the job calculation state, stored as an attribute
with the key
state
on theCalcJobNode
has changed significantly.The original job calculations had a calculation state that controlled
the logic during its lifetime. This was already superceded a long time
ago by the process wrapper that now fully governs the progression of the
calculation. Despite the calculation state no longer being authoritative
during the calculation's lifetime, it was still present. Here we finally
fully remove and only leave a stripped down version. The remaining state
is stored as an attribute and is a sub state while the
CalcJob
processis in an active state and serves as a more granual state that can be
queried for. This is useful, because the process status, which also
keeps similar information is human readable and doesn't allow for easy
querying.