I'm working on a project with has different checklists (questions and answers) associated with an entity (Protocol). There is a business requirement to have these questions be altered in the future and when a new entity is created it would be associated with the current checklist.
Example:
Lets say there is a checklist and has 21 questions (the actual questions are nested with questions having other questions but I believe this is out of the scope of this question). This would be version 1.0
. Something changes and now there are 22 questions and the version would be bumped up to 1.1
.
When a new Protocol
is created, it needs to have a Checklist
associated with it - the current Checklist
.
Simplified classes:
class Checklist {
String version
List<ChecklistQuestion> checklistQuestions
}
class ChecklistAnswerSet {
Checklist checklist
List<ChecklistAnswer> checklistAnswer
}
class Protocol {
ChecklistAnswerSet checklistAnswerSet
...
}
New Protocol
's are created within the ProtocolService
; the child checklistAnswerSet
is also created here as well but needs to refer to the current Checklist
instance.
We are working with a grails backend and it's extremely easy getting references to instances by their fields:
Checklist checklist = Checklist.findByVersion('1.1')
I could drop this in my ProtocolService
to get the current instance but I know this isn't a good idea. Any changes to this version would require code changes to the Service and although I could avoid a redeploy (grails magic), this feels completely wrong.
Where do I store this 1.1
? In a configuration file? In the database? Or am I completely wrong and my design needs a complete rework?
Initially, I was storing this 1.1
data within a generic key/value table we have in the database called System_Property
, but it just felt wrong. My gut reaction is to use a configuration file (there are other Checklist
's and therefore other current versions that would also go here), but a coworker is saying only environmental settings go in config files.