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

109 lines
2.7 KiB
CoffeeScript
Raw Normal View History

Stop aggresively using the reviver in fromJSON, conver model base class to ES2016
2017-07-08 03:27:09 +08:00
Model = require('../../src/flux/models/model').default
es6(models): Remaining models => ES2016 # Conflicts: # src/flux/models/contact.coffee
2016-10-27 07:01:23 +08:00
Category = require('../../src/flux/models/category').default
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'
Remove Attributes.ServerId
2017-06-25 11:03:35 +08:00
'serverId': Attributes.String
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
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.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'
Remove Attributes.ServerId
2017-06-25 11:03:35 +08:00
'serverId': Attributes.String
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
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.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.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'
Remove Attributes.ServerId
2017-06-25 11:03:35 +08:00
'serverId': Attributes.String
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
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.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'
Remove Attributes.ServerId
2017-06-25 11:03:35 +08:00
'serverId': Attributes.String
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
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.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'
Remove Attributes.ServerId
2017-06-25 11:03:35 +08:00
'serverId': Attributes.String
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
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'
module.exports = TestModel
Reference in a new issue Copy permalink