Relative time queries#4289
Conversation
| }) | ||
| .then((results) => { | ||
| expect(results.length).toBe(0); | ||
| }) |
There was a problem hiding this comment.
Considering that we have a test for getting at least one of each object, and one for neither, can we add one that returns both objects? Something using q.greaterThan('ttl', { $relativeTime: '3 days ago' }); is what comes to mind.
| parts = parts.filter((part) => part !== ''); | ||
|
|
||
| const future = parts[0] === 'in'; | ||
| const past = parts[parts.length - 1] === 'ago'; |
There was a problem hiding this comment.
Hmm, wondering if these should be case insensitive. We could lowercase the entire string in advance before processing.
There was a problem hiding this comment.
| // strip the 'ago' or 'in' | ||
| if (future) { | ||
| parts = parts.slice(1); | ||
| } else if (past) { |
There was a problem hiding this comment.
Do we need to do a check for past? Unless there's something else we're planning to add you could just use else.
spec/ParseQuery.spec.js
Outdated
| ttl: new Date(now - 2 * 24 * 60 * 60 * 1000), // 2 days ago | ||
| }); | ||
|
|
||
| dropDatabase() |
There was a problem hiding this comment.
you don't need that, the DB is dropped between each test
spec/helper.js
Outdated
| require(library)[name] = libraryCache[library][name]; | ||
| } | ||
|
|
||
| const { MongoClient } = require('mongodb'); |
| switch(interval) { | ||
| case 'day': | ||
| case 'days': | ||
| seconds += val * 24 * 60 * 60; |
There was a problem hiding this comment.
We can just use 2880 (3600, oops..., wow 86400...) rather than performing the multiplication each time, but you could leave a comment to detail it if needed.
|
|
||
| case 'hour': | ||
| case 'hours': | ||
| seconds += val * 60 * 60; |
| case 'seconds': | ||
| seconds += val; | ||
| break; | ||
|
|
There was a problem hiding this comment.
Just a thought, but we could support shorthand interval values like sec, min, hr and their plurals. Not necessarily needed however.
| let seconds = 0; | ||
| for (const [num, interval] of pairs) { | ||
| const val = Number(num); | ||
| if (!Number.isInteger(val)) { |
There was a problem hiding this comment.
With only whole integer values allowed perhaps we should add a test that expects to fail when someone tries something like 2.5 days.
There was a problem hiding this comment.
From the code, as interpolated to seconds, it seems that it should work with non Integer values no?
There was a problem hiding this comment.
Makes sense it would work, but we would want to test for it if we decide to allow it (or disallow it as currently).
There was a problem hiding this comment.
let's stick with integers for now.
montymxb
left a comment
There was a problem hiding this comment.
Some recommendations and ideas for moving this along. The coverage is kind of low too, before this goes in we'll probably have addressed that however.
Overall this is super cool! The logic is pretty clean for converting from relative time textually on top of it, nice job.
| case '$exists': | ||
| case '$ne': | ||
| case '$eq': | ||
| case '$eq': { |
There was a problem hiding this comment.
we may enter on some weird expectations here: $ne { $relativeTime: "1 day ago" } would you expect all object that were created the full day before to be excluded or just the one that matches perfectly the current time?
There was a problem hiding this comment.
@montymxb what do you think? Should we limit to $lt/$lte/$gt/$gte to be safe?
There was a problem hiding this comment.
Hmm, it would make the most sense with the query methods you've mentioned above, but not sure if we should simply rule out $ne/$eq. Although they may not be the most effective query methods with relative date matching they could still work, especially if we allow setting the now date in the future (but still not that great).
I would just say exclude those, but if someone expects it to work what would we return? Just an empty response like the query matched nothing, or provide some sort of error clarifying that equal/notEqual ops are not allowed using this param, or another approach perhaps.
There was a problem hiding this comment.
Or throw an error, that relativeDates operators don’t work with those operators
There was a problem hiding this comment.
That would work for me 👍 . Simplifying the initial implementation may be best, we can consider it later if someone actually needs to use it.
hr, hrs min, mins sec, secs
0ccf228 to
dc61f91
Compare
|
Thanks for reviewing. I had to rebase against master because of a failing test. I've addressed the issues raised in the review in "'Add integration test for multiple results' f8ce556" and the following commits. |
|
@montymxb this all look good to me! |
|
Changes look good, but the CI looks out of date. I'm going to bring this up to date with the master to retrigger build/coverage checking. I'm expecting it to come up as a ✓ (or close) but I want to see for certain before I give this an approval. |
Codecov Report
@@ Coverage Diff @@
## master #4289 +/- ##
==========================================
- Coverage 92.53% 92.49% -0.04%
==========================================
Files 118 118
Lines 8196 8246 +50
==========================================
+ Hits 7584 7627 +43
- Misses 612 619 +7
Continue to review full report at Codecov.
|
Context
I would like to be able to create queries where the current time is injected by Parse.
For example:
The future
This type of query can be serialized and re-executed at any time. I plan on adding support for recurring push notifications and relative time queries are essential for this feature.
It would look something like this (#4105):