NB - This is a WIP and the process/details are probably going to change along the way. This is more of an introduction to the idea and a preliminary explanation of the process.
Also see:
A module is a system or subsystem that performs some sort of task. A module may be a complete project, or a subsection of a project that you may need to reuse in other locations.
- A module exists in two parts:
- The spec sheet
- The config sheet
Examples:
- prism
- voucher platform
- file upload
- etc.
This is a .yaml file that contains a full list of the parts and processess required for recreating the module.
A spec sheet should contain:
- Tables - any tables as well as how they should be created in the new database, and what data should be included in the tables.
- strategy: The method of inserting the data into a new table i.e "replace", "insert ignore", etc.
- truncate (true/false): Whether or not the table should be truncated before new data is imported.
- has_entries (y/n/all): Are there any entries in the table that we need to include for the module to work? y - there are some entries, n - there are no entries, all - all the entries are necessary.
- Config options - any options in config.yaml that are necessary for the module to be run. These will be generated as blank (to not copy API keys, etc.), and will need to be manually entered.
- Files - files that may be needed. Things like logo images, etc.
- SQL Queries - These queries will recreate the necessary tables for the module and add in the necessary data.
- Bash commands - May also contain bash commands to copy in necessary files. Can copy files via http, or make new files, etc.
- The spec sheet and config sheet will be generated rather than put together by hand.
- The config sheet will be generated according to the spec sheet.
- The spec sheet will read from a database. A process will loop over the tables, read their descriptions, and determine which tables belong to which module.
- The description can also contain a list of instructions on how to recreate the table and it's data.
- A module column in the tables will determine which entries are required for the module.
- Module column should probably be able to accept comma separated values, for entries belonging to different modules (?).
- Some tables will belong to multiple modules i.e def_report. This