Foundry376/Mailspring
1
1
Fork 0
mirror of https://github.com/Foundry376/Mailspring.git synced 2024-09-21 15:56:10 +08:00
Code Issues Packages Projects Releases Wiki Activity
Mailspring/spec/fixtures/db-test-model.coffee

113 lines
3 KiB
CoffeeScript
Raw Normal View History

WIP: This is the initial diff for new folders & labels. Summary: There are now two objects, Folders & Labels. These inherit from `Category` (that's what Eben said they were using on the backend). There are two separate tasks. 1. MoveToFolderTask 2. ApplyLabelsTask It turns out that the semantics between the two are quite different. The reverse operation for moving to a folder is a bit tricky. As of 7-8-15, the Tasks are pretty much complete. I need to write tests for them still and do some manual testing in the client. Test Plan: Writing specs Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1724
2015-07-16 23:54:20 +08:00
Label = require '../../src/flux/models/label'
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
Model = require '../../src/flux/models/model'
Attributes = require '../../src/flux/attributes'
class TestModel extends Model
@attributes =
'id': Attributes.String
queryable: true
modelKey: 'id'
refactor(db): change ID system to have clientIDs and serverIDs Summary: Major ID refactor Test Plan: edgehill --test Reviewers: bengotow, dillon Differential Revision: https://phab.nylas.com/D1946
2015-08-29 02:12:53 +08:00
'clientId': Attributes.String
queryable: true
modelKey: 'clientId'
jsonKey: 'client_id'
'serverId': Attributes.ServerId
queryable: true
modelKey: 'serverId'
jsonKey: 'server_id'
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
TestModel.configureBasic = ->
TestModel.additionalSQLiteConfig = undefined
TestModel.attributes =
'id': Attributes.String
queryable: true
modelKey: 'id'
refactor(db): change ID system to have clientIDs and serverIDs Summary: Major ID refactor Test Plan: edgehill --test Reviewers: bengotow, dillon Differential Revision: https://phab.nylas.com/D1946
2015-08-29 02:12:53 +08:00
'clientId': Attributes.String
queryable: true
modelKey: 'clientId'
jsonKey: 'client_id'
'serverId': Attributes.ServerId
queryable: true
modelKey: 'serverId'
jsonKey: 'server_id'
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
TestModel.configureWithAllAttributes = ->
TestModel.additionalSQLiteConfig = undefined
TestModel.attributes =
'datetime': Attributes.DateTime
queryable: true
modelKey: 'datetime'
'string': Attributes.String
queryable: true
modelKey: 'string'
jsonKey: 'string-json-key'
'boolean': Attributes.Boolean
queryable: true
modelKey: 'boolean'
'number': Attributes.Number
queryable: true
modelKey: 'number'
'other': Attributes.String
modelKey: 'other'
TestModel.configureWithCollectionAttribute = ->
TestModel.additionalSQLiteConfig = undefined
TestModel.attributes =
'id': Attributes.String
queryable: true
modelKey: 'id'
refactor(db): change ID system to have clientIDs and serverIDs Summary: Major ID refactor Test Plan: edgehill --test Reviewers: bengotow, dillon Differential Revision: https://phab.nylas.com/D1946
2015-08-29 02:12:53 +08:00
'clientId': Attributes.String
queryable: true
modelKey: 'clientId'
jsonKey: 'client_id'
'serverId': Attributes.ServerId
queryable: true
modelKey: 'serverId'
jsonKey: 'server_id'
WIP: This is the initial diff for new folders & labels. Summary: There are now two objects, Folders & Labels. These inherit from `Category` (that's what Eben said they were using on the backend). There are two separate tasks. 1. MoveToFolderTask 2. ApplyLabelsTask It turns out that the semantics between the two are quite different. The reverse operation for moving to a folder is a bit tricky. As of 7-8-15, the Tasks are pretty much complete. I need to write tests for them still and do some manual testing in the client. Test Plan: Writing specs Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1724
2015-07-16 23:54:20 +08:00
'labels': Attributes.Collection
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
queryable: true
WIP: This is the initial diff for new folders & labels. Summary: There are now two objects, Folders & Labels. These inherit from `Category` (that's what Eben said they were using on the backend). There are two separate tasks. 1. MoveToFolderTask 2. ApplyLabelsTask It turns out that the semantics between the two are quite different. The reverse operation for moving to a folder is a bit tricky. As of 7-8-15, the Tasks are pretty much complete. I need to write tests for them still and do some manual testing in the client. Test Plan: Writing specs Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1724
2015-07-16 23:54:20 +08:00
modelKey: 'labels'
itemClass: Label
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
TestModel.configureWithJoinedDataAttribute = ->
TestModel.additionalSQLiteConfig = undefined
TestModel.attributes =
'id': Attributes.String
queryable: true
modelKey: 'id'
refactor(db): change ID system to have clientIDs and serverIDs Summary: Major ID refactor Test Plan: edgehill --test Reviewers: bengotow, dillon Differential Revision: https://phab.nylas.com/D1946
2015-08-29 02:12:53 +08:00
'clientId': Attributes.String
queryable: true
modelKey: 'clientId'
jsonKey: 'client_id'
'serverId': Attributes.ServerId
queryable: true
modelKey: 'serverId'
jsonKey: 'server_id'
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
'body': Attributes.JoinedData
modelTable: 'TestModelBody'
modelKey: 'body'
TestModel.configureWithAdditionalSQLiteConfig = ->
TestModel.attributes =
'id': Attributes.String
queryable: true
modelKey: 'id'
refactor(db): change ID system to have clientIDs and serverIDs Summary: Major ID refactor Test Plan: edgehill --test Reviewers: bengotow, dillon Differential Revision: https://phab.nylas.com/D1946
2015-08-29 02:12:53 +08:00
'clientId': Attributes.String
modelKey: 'clientId'
jsonKey: 'client_id'
'serverId': Attributes.ServerId
modelKey: 'serverId'
jsonKey: 'server_id'
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
'body': Attributes.JoinedData
modelTable: 'TestModelBody'
modelKey: 'body'
TestModel.additionalSQLiteConfig =
setup: ->
feat(accounts): Kill namespaces, long live accounts Summary: This diff replaces the Namespace object with the Account object, and changes all references to namespace_id => account_id, etc. The endpoints are now `/threads` instead of `/n/<id>/threads`. This diff also adds preliminary support for multiple accounts. When you log in, we now log you in to all the attached accounts on edgehill server. From the preferences panel, you can auth with / unlink additional accounts. Shockingly, this all seems to pretty much work. When replying to a thread, you cannot switch from addresses. However, when creating a new message in a popout composer, you can change the from address and the SaveDraftTask will delete/re-root the draft on the new account. Search bar doesn't need to do full refresh on clear if it never committed Allow drafts to be switched to a different account when not in reply to an existing thread Fix edge case where ChangeMailTask throws exception if no models are modified during performLocal Show many dots for many accounts in long polling status bar add/remove accounts from prefs Spec fixes! Test Plan: Run tests, none broken! Reviewers: evan, dillon Reviewed By: evan, dillon Differential Revision: https://phab.nylas.com/D1928
2015-08-22 06:29:58 +08:00
['CREATE INDEX IF NOT EXISTS ThreadListIndex ON Thread(last_message_received_timestamp DESC, account_id, id)']
refactor(DB): promisify database Summary: WIP. The app launches and works for me. I still need to fix the tests just the DB ones though :D I changed the `DatabaseProxy` into a `DatabaseConnection` object. It will request a fully instantiated databse from the backend Browser. If we're already setup, it'll connect straight to the existing DB. If we're not setup, then it'll create a new database and run the inital schema migration on it. The `_createNewDatabase` promise won't resolve until the migration has run. Until we add in a more sophisticated migration system and get rid of the stupid `modelClassMap` that's shoved in `Utils`, I'm passing in a series of `_setupQueries()` to get everything started. The `DatabaseConnection` is also the one responsible for queuing up queries until the DB is fully populated and ready to go. We actually get a lot of queries before we're setup because a lot of Stores will make DB requests on `require` in their `constructor` or `init` methods. (remember all the times we call `_populateStore` in `init`). Now those queries are aggregated by the `DatabaseConnection` and then executed sequentially. Our methods like `persistModel` now resolve only after both the queries have completed AND their corresponding `triggerLater` has completed as well. Test Plan: in progress Reviewers: bengotow Reviewed By: bengotow Differential Revision: https://phab.nylas.com/D1688
2015-06-26 22:42:41 +08:00
module.exports = TestModel
Reference in a new issue Copy permalink