Currently, tags are modelled as a comma-separated string on each rule. Modelling them in a separate table will make working with them simpler, for example modifying tags that are shared across many rules, or pulling a list of all unique tags.
This PR adds:
a tags table
methods to add, update, and remove tags
tests for those methods
It does not add a rules join table (though that will be the next piece of tags work) or add any means of managing tags to our frontend.
How to test
Run the application locally according to the instructions in the readme. Does it build? (This will show that the DB evolution has succeeded)
What does this change?
Currently, tags are modelled as a comma-separated string on each rule. Modelling them in a separate table will make working with them simpler, for example modifying tags that are shared across many rules, or pulling a list of all unique tags.
This PR adds:
It does not add a rules join table (though that will be the next piece of tags work) or add any means of managing tags to our frontend.
How to test
sbt test
). Do they all pass?