You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure how do you input new data, but it looks like some of mongo documents have very different properties within same collection. It is important to know what to expect in the results form the api user perspective.
So main question is about approach to take to make api useful for it's users that need to make assumptions about what to expect in results. We could track it in tests, or we could validate data when being put into db. In this use case, making extensive input tools might be not worth the effort, so we might run travis on master on schedule instead (don't remember if Travis allows to run tests on demand).
The text was updated successfully, but these errors were encountered:
I think the capsule data shouldn't be with the other rocket data, so all the rockets can have the same schema. I'll create a new collection and endpoint for capsule data at some point this week 👍
The schema changes are live now, all rockets should have exactly the same structure, solving the inconsistency issue. Dragon data is now on its own collection and endpoint as well.
I'm not sure how do you input new data, but it looks like some of mongo documents have very different properties within same collection. It is important to know what to expect in the results form the api user perspective.
I started a branch to add more assertions for results https://github.com/Srokap/SpaceX-API/tree/more_assertions and noticed that ie. dragon capsule and falcon rockets data differs wildly. The launches data has single launch with missing UTC timestamp.
So main question is about approach to take to make api useful for it's users that need to make assumptions about what to expect in results. We could track it in tests, or we could validate data when being put into db. In this use case, making extensive input tools might be not worth the effort, so we might run travis on master on schedule instead (don't remember if Travis allows to run tests on demand).
The text was updated successfully, but these errors were encountered: