Foundry376/Mailspring
1
1
Fork 0
mirror of https://github.com/Foundry376/Mailspring.git synced 2024-11-14 13:44:41 +08:00
Code Issues Projects Releases Packages Wiki Activity
Mailspring/spec/fixtures/db-test-model.coffee

117 lines
3.1 KiB
CoffeeScript
Raw Normal View History

DatabaseTransaction / QueryBuilder spec fixes
2016-01-26 03:11:57 +08:00
Category = require '../../src/flux/models/category'
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'
es6(db): Didn’t wait for NylasLint…
2016-09-22 00:40:06 +08:00
Attributes = require('../../src/flux/attributes').default
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
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'
perf(db): Use subselect to improve thread list query perf (53%!) Summary: - Use a sub-select query with much better performance to display the thread list - Perform analyze on tables after launch The new query is: ``` SELECT `Thread`.`data` FROM `Thread` WHERE `Thread`.`id` IN (SELECT `id` FROM `ThreadCategory` AS `M26` WHERE `M26`.`value` IN ('9m9ks71k06n5rmx82kgues09p','9s9k25q6j1krjgpkovbcjm7d','13b7ufruoymvih07ki0uahlto','dtmhlzz6phr47zp512knhjgf8','16dvjb84bszfh15kgfrjj37i3','aclwmgncdqjfibp51bvgbeik','17qad7jhbp6tozog3klm5zagt','4x4bkbawiq825u4eu3aus8tll','7axr9f5f1lzpwm2rw2ghkirhq','dsnn660af0pmou2gg3nstga8a','361qr5rva1ieby2r0ec3sn0bm','10fyvba7pjyjgeyr5i65i1zri') AND `M26`.`in_all_mail` = 1 ORDER BY `M26`.`last_message_received_timestamp` DESC LIMIT 200 OFFSET 0) ORDER BY `Thread`.`last_message_received_timestamp` DESC; ` 0|0|0|SEARCH TABLE Thread USING INDEX Thread_id (id=?) 0|0|0|EXECUTE LIST SUBQUERY 1 1|0|0|SCAN TABLE Thread-Category AS M26 USING COVERING INDEX ThreadFancyIndex 1|0|0|EXECUTE LIST SUBQUERY 2 0|0|0|USE TEMP B-TREE FOR (only on 200 result items) ``` Which is twice as performant as: ``` SELECT `Thread`.`data` FROM `Thread` INNER JOIN `ThreadCategory` AS `M26` ON `M26`.`id` = `Thread`.`id` WHERE `M26`.`value` IN ('9m9ks71k06n5rmx82kgues09p','9s9k25q6j1krjgpkovbcjm7d','13b7ufruoymvih07ki0uahlto','dtmhlzz6phr47zp512knhjgf8','16dvjb84bszfh15kgfrjj37i3','aclwmgncdqjfibp51bvgbeik','17qad7jhbp6tozog3klm5zagt','4x4bkbawiq825u4eu3aus8tll','7axr9f5f1lzpwm2rw2ghkirhq','361qr5rva1ieby2r0ec3sn0bm','10fyvba7pjyjgeyr5i65i1zri') AND `M26`.`in_all_mail` = 1 ORDER BY `M26`.`last_message_received_timestamp` DESC LIMIT 200 OFFSET 0; 0|0|1|SCAN TABLE Thread-Category AS M26 USING COVERING INDEX ThreadFancyIndex 0|0|0|EXECUTE LIST SUBQUERY 1 0|1|0|SEARCH TABLE Thread USING INDEX Thread_id (id=?) ``` Test Plan: Broken! Reviewers: evan, juan Reviewed By: juan Differential Revision: https://phab.nylas.com/D2869
2016-04-12 04:29:05 +08:00
'other': Attributes.String
queryable: true,
modelKey: 'other'
DatabaseTransaction / QueryBuilder spec fixes
2016-01-26 03:11:57 +08:00
'categories': Attributes.Collection
perf(db): Use subselect to improve thread list query perf (53%!) Summary: - Use a sub-select query with much better performance to display the thread list - Perform analyze on tables after launch The new query is: ``` SELECT `Thread`.`data` FROM `Thread` WHERE `Thread`.`id` IN (SELECT `id` FROM `ThreadCategory` AS `M26` WHERE `M26`.`value` IN ('9m9ks71k06n5rmx82kgues09p','9s9k25q6j1krjgpkovbcjm7d','13b7ufruoymvih07ki0uahlto','dtmhlzz6phr47zp512knhjgf8','16dvjb84bszfh15kgfrjj37i3','aclwmgncdqjfibp51bvgbeik','17qad7jhbp6tozog3klm5zagt','4x4bkbawiq825u4eu3aus8tll','7axr9f5f1lzpwm2rw2ghkirhq','dsnn660af0pmou2gg3nstga8a','361qr5rva1ieby2r0ec3sn0bm','10fyvba7pjyjgeyr5i65i1zri') AND `M26`.`in_all_mail` = 1 ORDER BY `M26`.`last_message_received_timestamp` DESC LIMIT 200 OFFSET 0) ORDER BY `Thread`.`last_message_received_timestamp` DESC; ` 0|0|0|SEARCH TABLE Thread USING INDEX Thread_id (id=?) 0|0|0|EXECUTE LIST SUBQUERY 1 1|0|0|SCAN TABLE Thread-Category AS M26 USING COVERING INDEX ThreadFancyIndex 1|0|0|EXECUTE LIST SUBQUERY 2 0|0|0|USE TEMP B-TREE FOR (only on 200 result items) ``` Which is twice as performant as: ``` SELECT `Thread`.`data` FROM `Thread` INNER JOIN `ThreadCategory` AS `M26` ON `M26`.`id` = `Thread`.`id` WHERE `M26`.`value` IN ('9m9ks71k06n5rmx82kgues09p','9s9k25q6j1krjgpkovbcjm7d','13b7ufruoymvih07ki0uahlto','dtmhlzz6phr47zp512knhjgf8','16dvjb84bszfh15kgfrjj37i3','aclwmgncdqjfibp51bvgbeik','17qad7jhbp6tozog3klm5zagt','4x4bkbawiq825u4eu3aus8tll','7axr9f5f1lzpwm2rw2ghkirhq','361qr5rva1ieby2r0ec3sn0bm','10fyvba7pjyjgeyr5i65i1zri') AND `M26`.`in_all_mail` = 1 ORDER BY `M26`.`last_message_received_timestamp` DESC LIMIT 200 OFFSET 0; 0|0|1|SCAN TABLE Thread-Category AS M26 USING COVERING INDEX ThreadFancyIndex 0|0|0|EXECUTE LIST SUBQUERY 1 0|1|0|SEARCH TABLE Thread USING INDEX Thread_id (id=?) ``` Test Plan: Broken! Reviewers: evan, juan Reviewed By: juan Differential Revision: https://phab.nylas.com/D2869
2016-04-12 04:29:05 +08:00
queryable: true,
DatabaseTransaction / QueryBuilder spec fixes
2016-01-26 03:11:57 +08:00
modelKey: 'categories'
perf(db): Use subselect to improve thread list query perf (53%!) Summary: - Use a sub-select query with much better performance to display the thread list - Perform analyze on tables after launch The new query is: ``` SELECT `Thread`.`data` FROM `Thread` WHERE `Thread`.`id` IN (SELECT `id` FROM `ThreadCategory` AS `M26` WHERE `M26`.`value` IN ('9m9ks71k06n5rmx82kgues09p','9s9k25q6j1krjgpkovbcjm7d','13b7ufruoymvih07ki0uahlto','dtmhlzz6phr47zp512knhjgf8','16dvjb84bszfh15kgfrjj37i3','aclwmgncdqjfibp51bvgbeik','17qad7jhbp6tozog3klm5zagt','4x4bkbawiq825u4eu3aus8tll','7axr9f5f1lzpwm2rw2ghkirhq','dsnn660af0pmou2gg3nstga8a','361qr5rva1ieby2r0ec3sn0bm','10fyvba7pjyjgeyr5i65i1zri') AND `M26`.`in_all_mail` = 1 ORDER BY `M26`.`last_message_received_timestamp` DESC LIMIT 200 OFFSET 0) ORDER BY `Thread`.`last_message_received_timestamp` DESC; ` 0|0|0|SEARCH TABLE Thread USING INDEX Thread_id (id=?) 0|0|0|EXECUTE LIST SUBQUERY 1 1|0|0|SCAN TABLE Thread-Category AS M26 USING COVERING INDEX ThreadFancyIndex 1|0|0|EXECUTE LIST SUBQUERY 2 0|0|0|USE TEMP B-TREE FOR (only on 200 result items) ``` Which is twice as performant as: ``` SELECT `Thread`.`data` FROM `Thread` INNER JOIN `ThreadCategory` AS `M26` ON `M26`.`id` = `Thread`.`id` WHERE `M26`.`value` IN ('9m9ks71k06n5rmx82kgues09p','9s9k25q6j1krjgpkovbcjm7d','13b7ufruoymvih07ki0uahlto','dtmhlzz6phr47zp512knhjgf8','16dvjb84bszfh15kgfrjj37i3','aclwmgncdqjfibp51bvgbeik','17qad7jhbp6tozog3klm5zagt','4x4bkbawiq825u4eu3aus8tll','7axr9f5f1lzpwm2rw2ghkirhq','361qr5rva1ieby2r0ec3sn0bm','10fyvba7pjyjgeyr5i65i1zri') AND `M26`.`in_all_mail` = 1 ORDER BY `M26`.`last_message_received_timestamp` DESC LIMIT 200 OFFSET 0; 0|0|1|SCAN TABLE Thread-Category AS M26 USING COVERING INDEX ThreadFancyIndex 0|0|0|EXECUTE LIST SUBQUERY 1 0|1|0|SEARCH TABLE Thread USING INDEX Thread_id (id=?) ``` Test Plan: Broken! Reviewers: evan, juan Reviewed By: juan Differential Revision: https://phab.nylas.com/D2869
2016-04-12 04:29:05 +08:00
itemClass: Category,
joinOnField: 'id',
joinQueryableBy: ['other'],
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