Add Elembio, and generic, runfolder and lims shim classes#965
Add Elembio, and generic, runfolder and lims shim classes#965dkj wants to merge 5 commits intowtsi-npg:develfrom
Conversation
- Introduced npg_tracking::elembio::runfolder for Elembio runfolder metadata handling. - Created npg_tracking::runfolder as a generic wrapper for runfolder functionality. - Implemented manufacturer methods for both Elembio and Illumina runfolders. - Added tests for the new runfolder classes and their functionalities.
providing LIMS info from flowcell identification without product metrics
Cleanup the earlier Illumina based with elmbio overrides code: - Introduced a new role, npg_tracking::runfolder::folder, to encapsulate shared runfolder path and staging behavior. - Delegated metadata parsing to specific implementations for Elembio and Illumina runfolders. - Updated runfolder_path_is_valid method to recognize both Elembio and Illumina runfolder structures. - Enhanced test suite to validate the public API consistency between generic and concrete runfolder implementations. - Improved error handling and path inference logic for runfolder discovery.
with delegated attributes and methods for improved functionality especially for more backward compatibility
|
Extending |
|
|
||
| return [ | ||
| $self->mlwh_schema->resultset('UseqWafer')->search( | ||
| {batch_for_opentrons => $self->id_flowcell_lims}, |
There was a problem hiding this comment.
| {batch_for_opentrons => $self->id_flowcell_lims}, | |
| {id_wafer_lims => $self->id_flowcell_lims}, |
| q[Ultima Genomics] => { | ||
| driver_class => q[st::api::lims::ml_warehouse_flowcell::ultima], | ||
| resultset => q[UseqWafer], | ||
| query_column => q[batch_for_opentrons], |
There was a problem hiding this comment.
| query_column => q[batch_for_opentrons], | |
| query_column => q[id_wafer_lims], |
I think you're right, I think we should know the manufacturer and so be able to identify a lims driver to use, however:
The main motivation for the these lims shim driver additions was to be able to work purely from LIMS info, i.e. before NPG has populated any [edit: also a second look after a break makes me think there is quite a lot of refactoring possible in this PR. Flipping back to draft and 🙏 @mgcam ] |
Yes, that would be very useful. However, I am not sure this code achieves this goal since it still links into product metrics tables to get tag indexes. Probably there is a default to use sequential numbers, which I have not noticed. However, (1) sequential numbers will be inconsistent with the tag indexes we are generating now and (2) since for |
Add the required runfolder and lims querying methods (in new classes) to support npg_seq_pipeline running analyses, see wtsi-npg/npg_seq_pipeline#918