-
Notifications
You must be signed in to change notification settings - Fork 450
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
For readSnapshots middleware, add method and parameter properties to first parameter #263
Conversation
…perties The "readSnapshots" middleware function can now look like this: ``` function(request, next) { let { collection, snapshots, requestMethod, // 'fetch', 'query', etc. requestParams, // object whose shape can vary snapshotType, agent } = request; } ```
lib/backend.js
Outdated
@@ -578,7 +591,16 @@ Backend.prototype._query = function(agent, request, callback) { | |||
var backend = this; | |||
request.db.query(request.collection, request.query, request.fields, request.options, function(err, snapshots, extra) { | |||
if (err) return callback(err); | |||
backend._sanitizeSnapshots(agent, request.snapshotProjection, request.collection, snapshots, backend.SNAPSHOT_TYPES.current, function(err) { | |||
var requestContext = { | |||
requestMethod: 'query', // TODO: Should this distinguish between queryFetch and querySubscribe? |
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.
Question here for reviewers - This currently doesn't distinguish between "queryFetch" and the initial query issued by "querySubscribe". Should it?
The initial "querySubscribe" DB query is for all intents and purposes identical to the query issued by "queryFetch". The big difference is in whether a pub/sub subscription is registered.
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.
yes, let's make the method be the same name as the public method on Backend, so queryFetch
or querySubscribe
lib/backend.js
Outdated
@@ -353,20 +350,28 @@ Backend.prototype.getOpsBulk = function(agent, index, fromMap, toMap, callback) | |||
Backend.prototype.fetch = function(agent, index, id, callback) { | |||
var start = Date.now(); | |||
var projection = this.projections[index]; | |||
var collection = (projection) ? projection.target : index; | |||
var dbCollection = (projection) ? projection.target : index; |
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.
Let's leave this as collection
for this PR. we could consider changing it, but we'd want to be consistent everywhere
lib/backend.js
Outdated
if (err) return callback(err); | ||
var snapshotProjection = backend._getSnapshotProjection(backend.db, projection); | ||
var snapshots = [snapshot]; | ||
backend._sanitizeSnapshots(agent, snapshotProjection, collection, snapshots, backend.SNAPSHOT_TYPES.current, function(err) { | ||
var requestContext = { | ||
requestMethod: 'fetch', |
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.
let's use method
lib/backend.js
Outdated
backend._sanitizeSnapshots(agent, snapshotProjection, collection, snapshots, backend.SNAPSHOT_TYPES.current, function(err) { | ||
var requestContext = { | ||
requestMethod: 'fetch', | ||
requestParams: { |
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.
let's use parameters
lib/backend.js
Outdated
@@ -578,7 +591,16 @@ Backend.prototype._query = function(agent, request, callback) { | |||
var backend = this; | |||
request.db.query(request.collection, request.query, request.fields, request.options, function(err, snapshots, extra) { | |||
if (err) return callback(err); | |||
backend._sanitizeSnapshots(agent, request.snapshotProjection, request.collection, snapshots, backend.SNAPSHOT_TYPES.current, function(err) { | |||
var requestContext = { | |||
requestMethod: 'query', // TODO: Should this distinguish between queryFetch and querySubscribe? |
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.
yes, let's make the method be the same name as the public method on Backend, so queryFetch
or querySubscribe
- requestMethod -> method, requestParams -> parameters - Distinguish methods 'queryFetch' and 'querySubscribe'
snapshots: snapshots, | ||
snapshotType: snapshotType | ||
}; | ||
requestContext.collection = collection; |
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.
It might be a good optimisation to initialise these properties whenever requestContext
is initialised. It may be beneficial to declare a class
for clarity about what exact information we're expecting in the middleware.
lib/backend.js
Outdated
@@ -366,7 +363,15 @@ Backend.prototype.fetch = function(agent, index, id, callback) { | |||
if (err) return callback(err); | |||
var snapshotProjection = backend._getSnapshotProjection(backend.db, projection); | |||
var snapshots = [snapshot]; | |||
backend._sanitizeSnapshots(agent, snapshotProjection, collection, snapshots, backend.SNAPSHOT_TYPES.current, function(err) { | |||
var requestContext = { | |||
method: 'fetch', |
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.
It would be nice to move these magic strings into an object, similar to the middleware actions. Just to clarify which methods are available, and to make refactoring easy, etc.
Thanks for the review, changes made! Give it another look when you've got the chance. |
@ericyhwang changes look good to me. Just greenify the build, and I'll approve. |
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.
🚀
I hadn't merged in your changes from last week the first time, and your tests caught the fact that I needed to support the new method too - thanks! Tests and CI doing their job. :) |
#269 reported that this caused a regression in I'm going to revert this for now so that forks don't pick it up. I'll work on adding a test for the queryPoll+readSnapshots case, fix the issue, and create a new PR. |
When monitoring for unusual response sizes, it can be useful to record which client request was associated with the response. Unfortunately, ShareDB's current "readSnapshots" middleware, which is how you get info about snapshot responses, doesn't contain information about the associated request.
This PR adds a couple additional fields to the "readSnapshots" middleware's
request
param,method
andparameters
.The "readSnapshots" middleware function now has a first parameter
request
like this: