Mailspring/packages/client-app/spec/tasks/change-labels-task-spec.coffee

246 lines
12 KiB
CoffeeScript
Raw Normal View History

_ = require 'underscore'
Label = require('../../src/flux/models/label').default
Thread = require('../../src/flux/models/thread').default
Message = require('../../src/flux/models/message').default
Actions = require('../../src/flux/actions').default
fix(spec): add support for async specs and disable misbehaving ones More spec fixes replace process.nextTick with setTimeout(fn, 0) for specs Also added an unspy in the afterEach Temporarily disable specs fix(spec): start fixing specs Summary: This is the WIP fix to our spec runner. Several tests have been completely commented out that will require substantially more work to fix. These have been added to our sprint backlog. Other tests have been fixed to update to new APIs or to deal with genuine bugs that were introduced without our knowing! The most common non-trivial change relates to observing the `NylasAPI` and `NylasAPIRequest`. We used to observe the arguments to `makeRequest`. Unfortunately `NylasAPIRequest.run` is argumentless. Instead you can do: `NylasAPIRequest.prototype.run.mostRecentCall.object.options` to get the `options` passed into the object. the `.object` property grabs the context of the spy when it was last called. Fixing these tests uncovered several concerning issues with our test runner. I spent a while tracking down why our participant-text-field-spec was failling every so often. I chose that spec because it was the first spec to likely fail, thereby requiring looking at the least number of preceding files. I tried binary searching, turning on and off, several files beforehand only to realize that the failure rate was not determined by a particular preceding test, but rather the existing and quantity of preceding tests, AND the number of console.log statements I had. There is some processor-dependent race condition going on that needs further investigation. I also discovered an issue with the file-download-spec. We were getting errors about it accessing a file, which was very suspicious given the code stubs out all fs access. This was caused due to a spec that called an async function outside ot a `waitsForPromise` block or a `waitsFor` block. The test completed, the spies were cleaned up, but the downstream async chain was still running. By the time the async chain finished the runner was already working on the next spec and the spies had been restored (causing the real fs access to run). Juan had an idea to kill the specs once one fails to prevent cascading failures. I'll implement this in the next diff update Test Plan: npm test Reviewers: juan, halla, jackie Differential Revision: https://phab.nylas.com/D3501 Disable other specs Disable more broken specs All specs turned off till passing state Use async-safe versions of spec functions Add async test spec Remove unused package code Remove canary spec
2016-12-13 04:12:20 +08:00
NylasAPI = require('../../src/flux/nylas-api').default
2016-10-01 06:24:34 +08:00
DatabaseStore = require('../../src/flux/stores/database-store').default
ChangeLabelsTask = require('../../src/flux/tasks/change-labels-task').default
ChangeMailTask = require('../../src/flux/tasks/change-mail-task').default
{AccountStore, CategoryStore} = require 'nylas-exports'
{APIError} = require '../../src/flux/errors'
{Utils} = require '../../src/flux/models/utils'
testLabels = {}
testThreads = {}
fix(spec): add support for async specs and disable misbehaving ones More spec fixes replace process.nextTick with setTimeout(fn, 0) for specs Also added an unspy in the afterEach Temporarily disable specs fix(spec): start fixing specs Summary: This is the WIP fix to our spec runner. Several tests have been completely commented out that will require substantially more work to fix. These have been added to our sprint backlog. Other tests have been fixed to update to new APIs or to deal with genuine bugs that were introduced without our knowing! The most common non-trivial change relates to observing the `NylasAPI` and `NylasAPIRequest`. We used to observe the arguments to `makeRequest`. Unfortunately `NylasAPIRequest.run` is argumentless. Instead you can do: `NylasAPIRequest.prototype.run.mostRecentCall.object.options` to get the `options` passed into the object. the `.object` property grabs the context of the spy when it was last called. Fixing these tests uncovered several concerning issues with our test runner. I spent a while tracking down why our participant-text-field-spec was failling every so often. I chose that spec because it was the first spec to likely fail, thereby requiring looking at the least number of preceding files. I tried binary searching, turning on and off, several files beforehand only to realize that the failure rate was not determined by a particular preceding test, but rather the existing and quantity of preceding tests, AND the number of console.log statements I had. There is some processor-dependent race condition going on that needs further investigation. I also discovered an issue with the file-download-spec. We were getting errors about it accessing a file, which was very suspicious given the code stubs out all fs access. This was caused due to a spec that called an async function outside ot a `waitsForPromise` block or a `waitsFor` block. The test completed, the spies were cleaned up, but the downstream async chain was still running. By the time the async chain finished the runner was already working on the next spec and the spies had been restored (causing the real fs access to run). Juan had an idea to kill the specs once one fails to prevent cascading failures. I'll implement this in the next diff update Test Plan: npm test Reviewers: juan, halla, jackie Differential Revision: https://phab.nylas.com/D3501 Disable other specs Disable more broken specs All specs turned off till passing state Use async-safe versions of spec functions Add async test spec Remove unused package code Remove canary spec
2016-12-13 04:12:20 +08:00
xdescribe "ChangeLabelsTask", ->
beforeEach ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
# IMPORTANT: These specs do not run the performLocal logic of their superclass!
# Tests for that logic are in change-mail-task-spec.
spyOn(ChangeMailTask.prototype, 'performLocal').andCallFake =>
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
Promise.resolve()
spyOn(AccountStore, 'accountForItems').andReturn({id: 'a1'})
spyOn(CategoryStore, 'getTrashCategory').andReturn name: 'trash'
spyOn(CategoryStore, 'getInboxCategory').andReturn name: 'inbox'
spyOn(CategoryStore, 'getSpamCategory').andReturn name: 'spam'
spyOn(CategoryStore, 'getAllMailCategory').andReturn name: 'all'
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
spyOn(DatabaseStore, 'modelify').andCallFake (klass, items) =>
Promise.resolve items.map (item) =>
return testLabels[item] if testLabels[item]
return testThreads[item] if testThreads[item]
item
testLabels = @testLabels =
"l1": new Label({name: 'inbox', id: 'l1', displayName: "INBOX"}),
"l2": new Label({name: 'drafts', id: 'l2', displayName: "MyDrafts"})
"l3": new Label({name: null, id: 'l3', displayName: "My Label"})
testThreads = @testThreads =
2016-01-23 08:55:29 +08:00
't1': new Thread(id: 't1', categories: [@testLabels['l1']])
't2': new Thread(id: 't2', categories: _.values(@testLabels))
't3': new Thread(id: 't3', categories: [@testLabels['l2'], @testLabels['l3']])
@basicThreadTask = new ChangeLabelsTask
labelsToAdd: ["l1", "l2"]
labelsToRemove: ["l3"]
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
threads: ['t1']
describe "description", ->
it "should include the name of the added label if it's the only mutation and it was provided as an object", ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask(labelsToAdd: ["l1"], labelsToRemove: [], threads: ['t1'])
expect(task.description()).toEqual("Changed labels")
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask(labelsToAdd: [new Label(id: 'l1', displayName: 'LABEL')], labelsToRemove: [], threads: ['t1'])
expect(task.description()).toEqual("Added LABEL")
task = new ChangeLabelsTask(labelsToAdd: [new Label(id: 'l1', displayName: 'LABEL')], labelsToRemove: ['l2'], threads: ['t1', 't2'])
expect(task.description()).toEqual("Moved 2 threads to LABEL")
it "should include the name of the removed label if it's the only mutation and it was provided as an object", ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask(labelsToAdd: [], labelsToRemove: ["l1"], threads: ['t1'])
expect(task.description()).toEqual("Changed labels")
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask(labelsToAdd: [], labelsToRemove: [new Label(id: 'l1', displayName: 'LABEL')], threads: ['t1'])
expect(task.description()).toEqual("Removed LABEL")
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask(labelsToAdd: ['l2'], labelsToRemove: [new Label(id: 'l1', displayName: 'LABEL')], threads: ['t1'])
expect(task.description()).toEqual("Changed labels")
it "should pluralize properly", ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask(labelsToAdd: ["l2"], labelsToRemove: ["l1"], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Changed labels on 3 threads")
task = new ChangeLabelsTask(labelsToAdd: [new Label(id: 'l1', displayName: 'LABEL')], labelsToRemove: [], threads: ['t1', 't2'])
expect(task.description()).toEqual("Added LABEL to 2 threads")
it "should include special cases for some common cases", ->
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "all")], labelsToRemove: [new Label(name: 'inbox')], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Archived 3 threads")
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "trash")], labelsToRemove: [new Label(name: 'inbox')], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Trashed 3 threads")
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "spam")], labelsToRemove: [new Label(name: 'inbox')], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Marked 3 threads as Spam")
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "inbox")], labelsToRemove: [new Label(name: 'spam')], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Unmarked 3 threads as Spam")
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "inbox")], labelsToRemove: [new Label(name: 'all')], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Unarchived 3 threads")
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "inbox")], labelsToRemove: [new Label(name: 'trash')], threads: ['t1', 't2', 't3'])
expect(task.description()).toEqual("Removed 3 threads from Trash")
task = new ChangeLabelsTask(labelsToAdd: [new Label(name: "inbox")], labelsToRemove: [new Label(name: 'trash')], threads: ['t1'])
expect(task.description()).toEqual("Removed from Trash")
describe "_ensureAndUpdateLabels", ->
beforeEach ->
@task = new ChangeLabelsTask()
@account = {}
it "does not remove `all` if attempting to remove `all` without adding `trash` or `spam`", ->
toAdd = []
toRemove = [{name: 'all'}]
{labelsToAdd, labelsToRemove} = @task._ensureAndUpdateLabels(@account, toAdd, toRemove)
expect(labelsToRemove).toEqual([])
it "removes `trash` and `spam` if attempting to add `all` and not already removing them", ->
toRemove = []
toAdd = [{name: 'all'}]
{labelsToAdd, labelsToRemove} = @task._ensureAndUpdateLabels(@account, toAdd, toRemove)
expect(labelsToRemove).toEqual([{name: 'trash'}, {name: 'spam'}])
it "adds `all` if removing `trash` and not adding to `all` or `spam`", ->
toRemove = [{name: 'trash'}]
toAdd = []
{labelsToAdd, labelsToRemove} = @task._ensureAndUpdateLabels(@account, toAdd, toRemove)
expect(labelsToAdd).toEqual([{name: 'all'}])
it "removes `all` and `spam` if attempting to add `trash` and not already removing it", ->
toRemove = []
toAdd = [{name: 'trash'}]
{labelsToAdd, labelsToRemove} = @task._ensureAndUpdateLabels(@account, toAdd, toRemove)
expect(labelsToRemove).toEqual([{name: 'all'}, {name: 'spam'}])
it "adds `all` if removing `spam` and not adding to `all` or `trash`", ->
toRemove = [{name: 'spam'}]
toAdd = []
{labelsToAdd, labelsToRemove} = @task._ensureAndUpdateLabels(@account, toAdd, toRemove)
expect(labelsToAdd).toEqual([{name: 'all'}])
it "removes `all` and `trash` if attempting to add `spam` and not already removing it", ->
toRemove = []
toAdd = [{name: 'spam'}]
{labelsToAdd, labelsToRemove} = @task._ensureAndUpdateLabels(@account, toAdd, toRemove)
expect(labelsToRemove).toEqual([{name: 'all'}, {name: 'trash'}])
describe "performLocal", ->
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
it "should throw an exception if task has not been given a label, has been given messages, or no threads", ->
badTasks = [
new ChangeLabelsTask(),
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
new ChangeLabelsTask(threads: [123]),
new ChangeLabelsTask(threads: [123], messages: ["foo"]),
feat(transactions): Explicit (and faster) database transactions Summary: Until now, we've been hiding transactions beneath the surface. When you call persistModel, you're implicitly creating a transaction. You could explicitly create them with `atomically`..., but there were several critical problems that are fixed in this diff: - Calling persistModel / unpersistModel within a transaction could cause the DatabaseStore to trigger. This could result in other parts of the app making queries /during/ the transaction, potentially before the COMMIT occurred and saved the changes. The new, explicit inTransaction syntax holds all changes until after COMMIT and then triggers. - Calling atomically and then calling persistModel inside that resulted in us having to check whether a transaction was present and was gross. - Many parts of the code ran extensive logic inside a promise chained within `atomically`: BAD: ``` DatabaseStore.atomically => DatabaseStore.persistModel(draft) => GoMakeANetworkRequestThatReturnsAPromise ``` OVERWHELMINGLY BETTER: ``` DatabaseStore.inTransaction (t) => t.persistModel(draft) .then => GoMakeANetworkRequestThatReturnsAPromise ``` Having explicit transactions also puts us on equal footing with Sequelize and other ORMs. Note that you /have/ to call DatabaseStore.inTransaction (t) =>. There is no other way to access the methods that let you alter the database. :-) Other changes: - This diff removes Message.labels and the Message-Labels table. We weren't using Message-level labels anywhere, and the table could grow very large. - This diff changes the page size during initial sync from 250 => 200 in an effort to make transactions a bit faster. Test Plan: Run tests! Reviewers: juan, evan Reviewed By: juan, evan Differential Revision: https://phab.nylas.com/D2353
2015-12-18 03:46:05 +08:00
new ChangeLabelsTask(labelsToAdd: ['l2'], labelsToRemove: ['l1'], messages: [123]),
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
new ChangeLabelsTask(threads: "Thread"),
]
goodTasks = [
new ChangeLabelsTask(
labelsToAdd: ['l2']
labelsToRemove: ['l1']
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
threads: ['t1']
)
]
caught = []
succeeded = []
runs ->
[].concat(badTasks, goodTasks).forEach (task) ->
task.performLocal()
.then -> succeeded.push(task)
.catch (err) -> caught.push(task)
waitsFor ->
succeeded.length + caught.length == 6
runs ->
expect(caught.length).toEqual(badTasks.length)
expect(succeeded.length).toEqual(goodTasks.length)
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
it 'calls through to super performLocal', ->
task = new ChangeLabelsTask
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
labelsToAdd: ['l2']
labelsToRemove: ['l1']
threads: ['t1']
waitsForPromise =>
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task.performLocal().then =>
expect(task.__proto__.__proto__.performLocal).toHaveBeenCalled()
describe "retrieveModels", ->
describe "when object IDs are provided", ->
beforeEach ->
@task = new ChangeLabelsTask
labelsToAdd: ['l2']
labelsToRemove: ['l1']
threads: ['t1']
it 'resolves the objects before calling super', ->
waitsForPromise =>
@task.retrieveModels().then =>
expect(@task.labelsToAdd).toEqual([testLabels['l2']])
expect(@task.labelsToRemove).toEqual([testLabels['l1']])
expect(@task.threads).toEqual([testThreads['t1']])
describe "when objects are provided", ->
beforeEach ->
@task = new ChangeLabelsTask
labelsToAdd: [testLabels['l2']]
labelsToRemove: [testLabels['l1']]
threads: [testThreads['t1']]
it 'still has the objects when calling super', ->
waitsForPromise =>
@task.retrieveModels().then =>
expect(@task.labelsToAdd).toEqual([testLabels['l2']])
expect(@task.labelsToRemove).toEqual([testLabels['l1']])
expect(@task.threads).toEqual([testThreads['t1']])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
describe 'change methods', ->
describe "changesToModel", ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
it 'properly adds labels', ->
task = new ChangeLabelsTask
labelsToAdd: [testLabels['l1'], testLabels['l2']]
labelsToRemove: []
out = task.changesToModel(testThreads['t1'])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
expect(out).toEqual(labels: [testLabels['l1'], testLabels['l2']])
it 'properly removes labels', ->
task = new ChangeLabelsTask
labelsToAdd: []
labelsToRemove: [testLabels['l1'], testLabels['l2']]
out = task.changesToModel(testThreads['t3'])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
expect(out).toEqual(labels: [testLabels['l3']])
it 'properly adds and removes labels, ignoring labels that are both added and removed', ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask
labelsToAdd: [testLabels['l1'], testLabels['l2']]
labelsToRemove: [testLabels['l2'], testLabels['l3']]
out = task.changesToModel(testThreads['t1'])
expect(out).toEqual(labels: [testLabels['l1'], testLabels['l2']])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
it 'should return an == array of labels when no changes have occurred', ->
2016-01-23 08:55:29 +08:00
thread = new Thread(id: '1', categories: [testLabels['l2'], testLabels['l3'], testLabels['l1']])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask
labelsToAdd: [testLabels['l3'], testLabels['l1'], testLabels['l2']]
labelsToRemove: []
out = task.changesToModel(thread)
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
expect(_.isEqual(thread.labels, out.labels)).toBe(true)
it 'should not modify the input thread in any way', ->
2016-01-23 08:55:29 +08:00
thread = new Thread(id: '1', categories: [testLabels['l2'], testLabels['l1']])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
task = new ChangeLabelsTask
labelsToAdd: []
labelsToRemove: [testLabels['l2']]
out = task.changesToModel(thread)
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
expect(thread.labels.length).toBe(2)
expect(out.labels.length).toBe(1)
describe "requestBodyForModel", ->
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
it 'returns labels:<ids> for both threads and messages', ->
task = new ChangeLabelsTask()
out = task.requestBodyForModel(testThreads['t3'])
perf(*): Add indexes, optimize "shouldAcceptModel", optimize Tasks Summary: Consolidate the smarts from ChangeFolderTask into a generic ChangeMailTask ChangeMailTask: - only makes requests for threads / messages that actually changed - handles incrementing / decrementing locks - writes changes to the database in a single pass, and only writes modified models - encapsulates the undo state that was built into ChangeFolderTask This change means that ChangeLabelsTask enjoys the same "smarts" as ChangeFolderTask. Label changes resulting in no-ops do not create web requests, you can undo label changes and they go back to the correct previous state. Replace "UpdateThreadsTask" and "UpdateNylasObjectsTask" with subclasses based on the same code used for folder/labels This means that the naming and parameter sets are consistent for all thread/message changing tasks. It also means that starring/marking as use the same (tested) business logic and starring 999 already-starred threads doesn't create 999 requests. Go away DraftCountStore - nobody wants you in secondary windows Add "Debug query plans" option which prints out the steps the database is taking. Look for "SCAN" to now you're having a bad time. Make "version" field queryable, when we receive deltas/API response, find all versions of existing models in a single query without loading or parsing the objects Contact: Add index for lookup by email Label: add index for lookup by name Message: Add index for message body join table Test Plan: Run tests Reviewers: evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D1840
2015-08-06 06:53:08 +08:00
expect(out).toEqual(labels: ['l2', 'l3'])