Mailspring/spec-nylas/tasks/change-labels-task-spec.coffee

196 lines
8.2 KiB
CoffeeScript
Raw Normal View History

_ = require 'underscore'
Label = require '../../src/flux/models/label'
Thread = require '../../src/flux/models/thread'
Message = require '../../src/flux/models/message'
Actions = require '../../src/flux/actions'
NylasAPI = require '../../src/flux/nylas-api'
DatabaseStore = require '../../src/flux/stores/database-store'
ChangeLabelsTask = require '../../src/flux/tasks/change-labels-task'
{APIError} = require '../../src/flux/errors'
{Utils} = require '../../src/flux/models/utils'
testLabels = {}
testThreads = {}
testMessages = {}
describe "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(ChangeLabelsTask.__super__, 'performLocal').andCallFake =>
Promise.resolve()
spyOn(DatabaseStore, 'modelify').andCallFake (klass, items) =>
Promise.resolve items.map (item) =>
return testLabels[item] if testLabels[item]
return testThreads[item] if testThreads[item]
return testMessages[item] if testMessages[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 =
't1': new Thread(id: 't1', labels: [@testLabels['l1']])
't2': new Thread(id: 't2', labels: _.values(@testLabels))
't3': new Thread(id: 't3', labels: [@testLabels['l2'], @testLabels['l3']])
testMessages = @testMessages =
'm1': new Message(id: 'm1', labels: [@testLabels['l1']])
'm2': new Message(id: 'm2', labels: _.values(@testLabels))
'm3': new Message(id: 'm3', labels: [@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']
@basicMessageTask = 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
messages: ['m1']
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 on 1 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
task = new ChangeLabelsTask(labelsToAdd: [new Label(id: 'l1', displayName: 'LABEL')], labelsToRemove: [], threads: ['t1'])
expect(task.description()).toEqual("Added LABEL to 1 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
task = new ChangeLabelsTask(labelsToAdd: [new Label(id: 'l1', displayName: 'LABEL')], labelsToRemove: ['l2'], threads: ['t1'])
expect(task.description()).toEqual("Changed labels on 1 thread")
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 on 1 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
task = new ChangeLabelsTask(labelsToAdd: [], labelsToRemove: [new Label(id: 'l1', displayName: 'LABEL')], threads: ['t1'])
expect(task.description()).toEqual("Removed LABEL from 1 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
task = new ChangeLabelsTask(labelsToAdd: ['l2'], labelsToRemove: [new Label(id: 'l1', displayName: 'LABEL')], threads: ['t1'])
expect(task.description()).toEqual("Changed labels on 1 thread")
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")
describe "performLocal", ->
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 throw an exception if task has not been given a label, or messages and 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"]),
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']
)
new ChangeLabelsTask(
labelsToAdd: ['l2']
labelsToRemove: []
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
messages: ['m1']
)
]
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.constructor.__super__.performLocal).toHaveBeenCalled()
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 "when object IDs are provided", ->
beforeEach ->
@task = new ChangeLabelsTask
labelsToAdd: ['l2']
labelsToRemove: ['l1']
threads: ['t1']
it 'resolves the objects before calling super', ->
waitsForPromise =>
@task.performLocal().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.performLocal().then =>
expect(@task.labelsToAdd).toEqual([testLabels['l2']])
expect(@task.labelsToRemove).toEqual([testLabels['l1']])
expect(@task.threads).toEqual([testThreads['t1']])
describe 'change methods', ->
describe "_changesToModel", ->
it 'properly adds labels', ->
task = new ChangeLabelsTask
labelsToAdd: [testLabels['l1'], testLabels['l2']]
labelsToRemove: []
out = task._changesToModel(testThreads['t1'])
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'])
expect(out).toEqual(labels: [testLabels['l3']])
it 'properly adds and removes labels', ->
task = new ChangeLabelsTask
labelsToAdd: [testLabels['l1'], testLabels['l2']]
labelsToRemove: [testLabels['l2'], testLabels['l3']]
out = task._changesToModel(testThreads['t1'])
expect(out).toEqual(labels: [testLabels['l1']])
it 'should return an == array of labels when no changes have occurred', ->
thread = new Thread(id: '1', labels: [testLabels['l2'], testLabels['l3'], testLabels['l1']])
task = new ChangeLabelsTask
labelsToAdd: [testLabels['l3'], testLabels['l1'], testLabels['l2']]
labelsToRemove: []
out = task._changesToModel(thread)
expect(_.isEqual(thread.labels, out.labels)).toBe(true)
it 'should not modify the input thread in any way', ->
thread = new Thread(id: '1', labels: [testLabels['l2'], testLabels['l1']])
task = new ChangeLabelsTask
labelsToAdd: []
labelsToRemove: [testLabels['l2']]
out = task._changesToModel(thread)
expect(thread.labels.length).toBe(2)
expect(out.labels.length).toBe(1)
describe "_requestBodyForModel", ->
it 'returns labels:<ids> for both threads and messages', ->
task = new ChangeLabelsTask()
out = task._requestBodyForModel(testThreads['t3'])
expect(out).toEqual(labels: ['l2', 'l3'])
out = task._requestBodyForModel(testMessages['m3'])
expect(out).toEqual(labels: ['l2', 'l3'])