4 ms·
It's a bad idea and I'd like to see how do people actually do test using this model. Now you have to run PG locally everytime you need to unit test something? A
by Thaxll 5y ago
It's a bad idea and I'd like to see how do people actually do test using this model. Now you have to run PG locally everytime you need to unit test something? Also PG returns some JSON but if the object is not exactly what you want to send back you create another object and merge the two? Just don't do it, it's a terrible design. It "works" for simple API but for anything serious this is wrong.
- gigatexal 5y agoDocker run postgres… boom testing solved ;)
- Thaxll 5y agoFor DB that you can't run locally how do you do? or the CI/CD, there are a millions of example where people don't run the DB locally.
- kristiandupont 5y agoWhy can you not run PG locally?
- kerreks 5y agoIt's pretty common to run db locally in docker for integration testing these days
- tofuahdude 5y agoDid you read the article at all before criticizing it as "terrible design"? All its talking about are native postgres methods for pre-formatting data.
- midev 5y agoYou misunderstood the entire article. This is about formatting the data from Postgres. It doesn't change anything about your testing. If you're mocking data, you mock the JSON instead of raw rows. If you were doing integration tests, nothing changes anyway. > Also PG returns some JSON but if the object is not exactly what you want to send back you create another object and merge the two Sure. Literally nothing changes. Just as if you had to assemble a JSON blob from two Postgres queries and merge them. > Just don't do it, it's a terrible design. It "works" for simple API but for anything serious this is wrong I think you completely misunderstood the article. Returning a JSON object from a database query is not "wrong", and I've used this pattern with great success. It's so much easier to call a json_agg to turn a subquery into an array, than to try and manually parse out rows yourself in the middle layer.