feat: Add strand to FusionVariant output #157
Conversation
|
The reason that you are running into this problem, is that your local cache currently doesn't include the two new strands attributes. With your changes you will want to regenerate your local cache |
There was a problem hiding this comment.
@jarbesfeld it's good practice to add / update tests when including new functionality. I would recommend updating https://github.com/griffithlab/civicpy/blob/master/civicpy/tests/test_civic.py#L193
|
Updating the tests would be great but I think we should first narrow down how we want to approach this problem. IMHO, it would be good to pull back the full set of exon coordinates. This would require setting up a new ExonCoordinates class (similar to the Coordinates class which we might want to rename to GenomicCoordinates to match the updated CIViC schema). There are up to four sets of exon coordinates on a FusionVariant (depending on whether both partners are "known"): five_prime_start_exon_coordinates, five_prime_end_exon_coordinates, three_prime_start_exon_coordinates, three_prime_end_exon_coordinates that would all need to be added to the _COMPLEX_FIELDS list. The main difference is that I don't think we would want to include the exon coordinates in the COORDINATE_TABLE. If you update the tests you will also need to update the test_cache.pkl file. This is usually done by creating a new local cache after you make all of your changes and then copying that local cache to the above location. |
|
@susannasiebert I'm a bit unsure about the new class construction that you had mentioned, but I pushed an update with that includes a query for the four relevant exon coordinates. Would we still want to set up the new classes? |
|
It looks like you removed the genomic coordinates from the query. I think we will want to have both types. In regards to the classes, there might be a bug here where we aren't actually casting the genomic coordinates to the Coordinates class. It's been a while since I've looked at the code but I'm happy to dig into this if you would like. |
|
If you could take a look that would be great! I'm not entirely familiar with the class schemas so I may be overcomplicating this update. |
…tly parsed to (Exon)Coordinate objects
|
@jarbesfeld I have made the necessary updates to add the ExonCoordinate class and fix the bugs preventing the coordinates from getting parsed to (Exon)Coordinate objects. If you want to take it from here to add the appropriate tests, that would be great. Let me know if you have any questions. |
|
@susannasiebert Thanks for your help updating the |
| def test_attributes(self): | ||
| variant = civic.get_variant_by_id(1) | ||
| assert variant.vicc_compliant_name == 'BCR(entrez:613)::ABL1(entrez:25)' | ||
| assert variant.five_prime_coordinates.reference_build == 'GRCH37' |
There was a problem hiding this comment.
@jarbesfeld is there a reason why we aren't checking other attributes (reference build, offset, exon, etc)?
There was a problem hiding this comment.
@korikuzma It looks like exon_offset is set to None in the output. Not sure if this is because the offsets for this fusion are 0
There was a problem hiding this comment.
Not sure if this is because the offsets for this fusion are 0
That is correct. I could update the code to parse these to 0 if that sounds like a good idea (it's what we do on the CIViC frontend).
closes #156
This PR adds two new features to the
FusionVariantoutput:five_prime_strandandthree_prime_strand