search

sanger / limber

A config-driven LIMS built on Sequencescape, primarily for running library preparation pipelines in the laboratory
MIT License
3 stars 8 forks source link

GPL-638 new Library PCR consolidation #483

Closed rl15 closed 4 years ago

rl15 commented 4 years ago

User story GPL-638 | As a member of R&D (Lesley, Iraad, Emma B) we would like a new Library PCR consolidation to unite the parallel PCR paths for one sample prior to pooling

Who are the primary contacts for this story Lesley S Iraad B Emma B

Acceptance criteria To be considered successful the solution must allow:

**Risk?*** Tag clash (is same sample ID)

Additional context Workflows available: https://ssg-confluence.internal.sanger.ac.uk/x/u4meBg

JamesGlover commented 4 years ago

Again, this one should just work. Moving into In progress until I discover otherwise.

JamesGlover commented 4 years ago

From earlier discussions with Lesley it sounds like they expect to use the same 'one primer panel' option as in the original pipeline.

JamesGlover commented 4 years ago

😭 Not free after all, and sadly a little messy.

  1. Aliquot deduplication depends on the aliquots sharing the same properties, such that they can be consolidated into a single record.
  2. While we share tags, samples, library_types, primer panels, we have different library_ids
  3. Library id is set when tagging occurs, and it points to the receptacle in which the tag was first applied.
  4. This means that the aliquots can not be de-duplicated, as their attributes are different. (Ie. they aren't de-duplicates)
  5. Trying to insert them both into the aliquots table results in a tag clash, as they have identical tags.

Other notes:

  1. Tag clashes are enforced at the database level by a uniqueness constraint on receptacle_id,tag_id,tag2_id

Options:

  1. Somehow consolidate library_ids at the merge, to only have a single library. (Possibly using the merge well id.) Results in single aliquot, but slightly hampers tracking, and will break tag substitution unless we also update the library ids in the parent wells?
  2. Set the library ids earlier in the process, such as on the initial transfer using the source receptacle id. This is similar to point 1, but has the advantage that tag substitution works again... as long as both versions of the library need the same substitution. (But if they don't, you'd be in trouble anyway, as suddenly one library indeed becomes two)
  3. Add library_id to the uniqueness constraint. This is a pretty simple fix overall, and would result in two aliquots with different library ids, but all other options the same. It feels like the most accurate reflection of what's happened, but I'm not sure it'll gel great with the NPG view of the world, as they don't represent entities that can be deplexed. That idea was stupid. Adding the library id to the uniqueness constraint would of course allow pooling of completely unrelated stuff. We only want to allow the library id to differ if all other properties are the same. Adding it to the uniqueness constraint would not achieve this at all.

I had another idea but its slipped my mind as I'm writing this.