-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename APIs for feature density stats and quantitative stats #3618
Conversation
@@ -93,7 +93,7 @@ export abstract class BaseAdapter { | |||
public abstract freeResources(region: Region): void | |||
} | |||
|
|||
export interface Stats { | |||
export interface FeatureDensityStats { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this could potentially be changed to e.g. {featureDensity:number} | {bytes:number,fetchSizeLimit:number} but that requires additional code changes to make typescript happy, and i think it's ok to leave it as is for now
follow up comment to #3605 |
c51140b
to
a7248c9
Compare
Codecov Report
@@ Coverage Diff @@
## main #3618 +/- ##
==========================================
+ Coverage 63.06% 63.08% +0.02%
==========================================
Files 871 876 +5
Lines 30189 30177 -12
Branches 7269 7271 +2
==========================================
- Hits 19038 19037 -1
+ Misses 10966 10955 -11
Partials 185 185
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
one thing I became aware of is that it is a breaking behavior to 'use the new api instead of the old api' rename estimateStats->getStats on base adapter so, we can flip the naming around, and instead keep the core code calling the old thing, with the new getStats naming forwarding to the old one or, we can just call this a band-aid rip off thing and just roll with it |
or, have the 'display code' call both the old and new apis to thoroughly check as i think swapping old and new naming leads to same problem too... |
probably better to just rip off the band aid and not really have back compat if we do go through with renaming maybe |
I think I can think of a way to accomplish this renaming without breaking backcompat. How about this plan?
If I'm not forgetting anything, I think these steps would preserve backcompat while getting us to the point of having a uniform stats API consisting of 4 public methods:
which offer subclasses convenient opportunities for overriding or implementing what makes sense for them. What do you think of that plan? |
the backcompat that i am interested in would involve the data adapters not having to rename their methods. I think that trying to add that backcompat may be more effort than it is worth though. It would actually be easier for a plugin, if it is interested in adding that backcompat, changing itself, rather than core adding the code to do any backcompat e.g. a plugin could duplicate the methods in their code by having both estimateRegionsStats and getMultiRegionQuantitativeStats do the same thing if they want the backcompat, rather than core trying to bend around it... |
note also: as it stands, i do not have a singular version of getRegionFeatureDensityStats in the BaseAdapter API, just getMultiRegionFeatureDensityStats we could potentially add it, but I am not sure if is a good idea for getMultiRegionFeatureDensityStats to just call the getRegionFeatureDensityStats on every single region. That may result in a lot of time spent doing this feature density stats calculations for multi-region views. The current BaseAdapter code actually just looks at region 0. The index-based-byte-sized estimation from BAM/CRAM actually does incorporate all the regions, because it is fast to do so |
Yes I don't see any way around the data adapter subclasses needing to rename their methods. At the end of the day, I just want us to have an API for the data adapters that has good naming and can be subclassed by lots of different kinds of data adapters and still have the names make sense. I'm fine with just looking at region 0 in the getMulti* methods |
4ee265c
to
1c56973
Compare
this PR now doesn't make any effort to do back compat reasoning
|
1c56973
to
391cc4b
Compare
} catch (e) { | ||
self.setError(e) | ||
} | ||
superReload() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a rider change but i manually tested it and our integration tests also test it, don't need to manually do stats as autorun will do so after clearing the error
} catch (e) { | ||
self.setError(e) | ||
} | ||
superReload() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar here
391cc4b
to
c2e0c95
Compare
c2e0c95
to
14bb681
Compare
maybe can merge for now :) note @rbuels this may end up getting conflicts with your branch since it moves base adapter files around, one file per class |
sure that's fine
…On Tue, Apr 11, 2023 at 3:07 PM Colin Diesh ***@***.***> wrote:
maybe can merge for now :) note @rbuels <https://github.com/rbuels> this
may end up getting conflicts with your branch since it moves base adapter
files around, one file per class
—
Reply to this email directly, view it on GitHub
<#3618 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAASAFMCT2A4YTAES5L2X23XAXI2HANCNFSM6AAAAAAWNQQULU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Splits stats fetching into two 'categories': 'quantitative' stats and 'feature density' stats
Adds some back compat. does not rename the rpc method at the moment