artifact types addition
- Langage dominant
- Python
- Étoiles
- 1.2k
- Forks
- 303
- Merge moyen
- 4 h 32 min
- PR mergées (30 j)
- 216
Description
i have been thinking through the artifacts block and how to support these type of things more universally than the current implementation. i am thinking of 3 `artifact_type` options that would get declared in the artifact info block.
- `primary`: implied if nothing else is declared to ensure compatibility and not have to update 400 artifacts. exactly the same as current artifacts - no change
- `secondary`: would be similar to how the subsequent logarchive artifacts are currently being done. this type would declare a table dependency, and it would give the dev the option to read records from existing table(s) and do processing or converting to other stuff using python code. this would result in a new table of (possible duplicated) data just like logarchive things are doing now
- `view`: would be an artifact definition that would focus on creating a view inside sqlite. it would also declared a table dependency. this would not require any python code to create - only a sql statement. this is more aligned with the intention of the logarchive artifacts since those are not doing any converting or other data manipulation in python code. they are simply copying records that match a filter criteria into a new table. a view can be defined by a simple query that would use the original table as its source but apply the filter to get the limited data set
the LEAPP processor would identify the artifacts by tiers. tier 1 is primary only. tier 2 would have both secondary and view since both have table dependencies. LEAPP would run tier 1 to get data source, then selectively run tier 2 artifacts if the dependencies are satisfied (ie: table exists).
do we add `view` artifacts to HTML or other outputs?
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Évaluation
Cette issue n'a pas encore été évaluée.