While I was working with @ridmal on extending Initializer to handle programs, workflows and states I came across something weird.
In one of our tests we ended up adding the same workflow to two different programs (see here). This makes sense in the real world by the way, but our data model doesn’t quite support that situation adequately.
More specifically the issue is that ProgramWorkflow.getProgram() returns a single value (here). And it happens to be the last program to which the workflow was added.
I believe the general pattern is that a workflow is only valid for a single program… if you need the exact same workflow for two programs, it still needs up as two discreet workflows (though the workflows and states could link to the same concepts).
Not sure if there’s a strong reason to change that model?
Thanks @mogoodrich, that makes sense. However it turns out that Core doesn’t prevent to do it via the API, leading to an unstable behaviour of ProgramWorkflow.getProgram(). Do we agree that a validation should be added, or am I missing something?
For the time being we will prevent this use case through Initializer.
Thanks @mksd… would be worth confirming with others that my assumption above is correct (@burke@darius@mseaton), and, yes, if so, I would assume that we should add validation to prevent this.
What exactly would the validation do? As you say, ProgramWorkflow has a single Program property, and the program_workflow table has a program_id column. So there should be no confusion around whether or not a workflow can be associated with multiple programs.
All of the code is not included above, but it’s possible that those 2 programs do not actually contain the same workflow. Rather they might contain different workflows that were accidentally given the same uuid. I believe the “equals” method simply looks at matching uuids to determine equality.
@mseaton I wrote a test that highlights the issue here, the last assert fails. Perhaps this is in fact intended to be like this, but for now I have prevented this to be done with Iniz.
I see. Makes sense since the program has not be re-loaded from the DB. Definitely there is no problem guarding against this in the Initializer module with extra validation - thanks.
FWIW, I agree our data model is currently designed to have one program for a workflow, so Java API should prevent assignment of a workflow to more than one program. Some class level documentation might help promote a shared understanding.
@burke you seem to suggest that it should just to be documented to not do that, which would already help for sure.
My concern is that ProgramWorkflow.getProgram() is somewhat unreliable in the sense that it arbitrarily returns the last program the workflow was added to, when it is added to multiple programs.
Oh sorry. I didn’t mean to imply only documentation. I agree the API should prevent a workflow from being assigned to multiple programs. Just sayin’ a little documentation couldn’t hurt. For example, a javadoc class level comment for ProgramWorkflow saying something like:
/*
NOTE: A workflow can only be used within a single program (i.e., re-using the
same workflow for multiple programs is not currently supported; a workaround
would be to make a separate copy of the workflow for each program).
*/
For example, a javadoc class level comment for