Skip to content

Milestones

List view

  • Though the present splicing options and approach _can_ allow full sweep of use-cases to be met the present implementation doesn't scale well when it comes to needing to ignore a given entry from an alternative info source by setting an entry in the CMMS entry. For example. This dataset has a long list of parameters https://catalogue.ceda.ac.uk/uuid/f47bc62786394626b665e23b658d385f There is one labelled 'unknown' which the data provider has asked to be removed from the list. This is presently coming in from the FBI and the only way to do this at present is : 1. copy the full list of parameters as presently harvested 1. create a new CMMS record 1. insert all the parameters to keep 1. set the splicing rule to cmms_only This isn't desirable as : 1. The dataset may have new parameters coming in and needing to be exposed and then it becomes a large manual process 1. There may be a desire to do multiple splice actions - e.g. ignore one parameter and flesh out another parameter (using replace) or even also append more parameters. As such a fundamental re-engineering of CMMS entries needs to be made. - [ ] move splice rules to being listed under the section headings - [ ] each section then has a dictionary where the first level is the splice rule, this allows multiple splice rules to be listed Actions - [ ] scope out how to do the new splicing route - [ ] add in new splicing rule 'remove' - [ ] figure out how to re-engineer the CMMS structure to provide CMMS standard version indexes - [ ] re-engineer pyCMMS to cope with the alteration in the scraping - [ ] update test suite

    No due date
    0/5 issues closed