Before this PR:
KeyValueSnapshotReader (KVSR) does not exist.
After this PR:
==COMMIT_MSG==
KVSR exists, and calls to get and getRows go through it.
==COMMIT_MSG==
Priority: High P2
Concerns / possible downsides (what feedback would you like?):
The getRows API is weird. I do want to change it, but I think that should happen separately - I'd want us to reason through the allocation path and satisfy ourselves that we won't be causing (too many) additional allocations.
There's some duplication across KVSR and SnapshotTransaction because the other endpoints like getRowsColumnRange need the post-filtering logic still. This will go away at the end of Phase III, but until then this duplication exists. It is navigable through code search and this code is not frequently changed, and I'm not sure we can split this out more easily.
Is documentation needed?: No.
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?: No
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?: No
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.): Yes
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?: I don't think so
Does this PR need a schema migration? No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: That the SnapshotTransaction tests provide good enough coverage.
What was existing testing like? What have you done to improve it?: SnapshotTransaction is well tested.
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: N/A
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.): User calls still work
Has the safety of all log arguments been decided correctly?: I checked these, yes.
Will this change significantly affect our spending on metrics or logs?: No.
How would I tell that this PR does not work in production? (monitors, etc.): User calls don't work, service status/500s alerting.
If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?: Rollback
If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
Scale
Would this PR be expected to pose a risk at scale? Think of the shopping product at our largest stack.: No
Would this PR be expected to perform a large number of database calls, and/or expensive database calls (e.g., row range scans, concurrent CAS)?: No
Would this PR ever, with time and scale, become the wrong thing to do - and if so, how would we know that we need to do something differently?: Some of the duplication won't last.
Development Process
Where should we start reviewing?: KeyValueSnapshotReader
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?: It was hard to remove smaller components.
Please tag any other people who should be aware of this PR:
@jeremyk-91
@sverma30
@raiju
General
Before this PR:
KeyValueSnapshotReader
(KVSR) does not exist.After this PR:
==COMMIT_MSG== KVSR exists, and calls to
get
andgetRows
go through it. ==COMMIT_MSG==Priority: High P2
Concerns / possible downsides (what feedback would you like?):
getRows
API is weird. I do want to change it, but I think that should happen separately - I'd want us to reason through the allocation path and satisfy ourselves that we won't be causing (too many) additional allocations.SnapshotTransaction
because the other endpoints like getRowsColumnRange need the post-filtering logic still. This will go away at the end of Phase III, but until then this duplication exists. It is navigable through code search and this code is not frequently changed, and I'm not sure we can split this out more easily.Is documentation needed?: No.
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?: No
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?: No
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.): Yes
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?: I don't think so
Does this PR need a schema migration? No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: That the SnapshotTransaction tests provide good enough coverage.
What was existing testing like? What have you done to improve it?: SnapshotTransaction is well tested.
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: N/A
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.): User calls still work
Has the safety of all log arguments been decided correctly?: I checked these, yes.
Will this change significantly affect our spending on metrics or logs?: No.
How would I tell that this PR does not work in production? (monitors, etc.): User calls don't work, service status/500s alerting.
If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?: Rollback
If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
Scale
Would this PR be expected to pose a risk at scale? Think of the shopping product at our largest stack.: No
Would this PR be expected to perform a large number of database calls, and/or expensive database calls (e.g., row range scans, concurrent CAS)?: No
Would this PR ever, with time and scale, become the wrong thing to do - and if so, how would we know that we need to do something differently?: Some of the duplication won't last.
Development Process
Where should we start reviewing?: KeyValueSnapshotReader
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?: It was hard to remove smaller components.
Please tag any other people who should be aware of this PR: @jeremyk-91 @sverma30 @raiju