mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
f4563457e8
Rewrote parts of the update server package data unit test to compare a pre-sync and a post-sync catalog, rather than the output of package client's attempts to contact the server. This is because in the new world, there is no accurate output, and instead, the function modifies the catalog in place. Additionally, removed the old function that read from data.json, since it was not used anymore, and cleaned up some comments and return values in package-client. We no longer claim to return the contents of data.json, instead we return an object that signals if we should reset the entire catalog, and/or if our connection to the server flat-out failed. I am not sure that this is the best abstraction for this piece of code (why does package-client modify the catalog, but not reset it, for example? Since resetting has consequences, in the ideal world, the package-client would only have the logic to get data from the server and it would be up to the catalog to figure out how to insert it into sql lite, I think, maybe. Regardless, now is not the time to do that refactoring.) The test is a little odd in the following ways. First, comparing every record ever published is something that is already significantly harder than it used to be, and will get only harder from there. (However, the test claims to check that no data has been erased, so we need to check it). We check the vague existence of most records, on the theory that it is unlikely that we only got a portion of the record in, rather than the entire thing. Second, it doesn't check the actual contents on disk, because I wasn't sure about writing another interface to sqllite this late in the game. There are some ways to get around this -- we could be sneaky and submit a non-blank syncToken in some way (faking a previous sync), so we only get the packages touched since (time X). Usually, that might violate some internal consistency, but we only care about the contents at this stage. Second, we should probably write some method on the catalogs to compare themselves instead of making and querying a copy.For now, though, I think that this is sufficiently expedient. Also, the test publishes 5 packages. That's a lot of packages, so I marked it as slow.