3 ms·
I followed this approach once and ended up abandoning a week's worth of work because it was just far too slow (hours vs < 1 minute) when running on large quanti
by MoreQARespect 3y ago
I followed this approach once and ended up abandoning a week's worth of work because it was just far too slow (hours vs < 1 minute) when running on large quantities of data.
>This leaves more room for error and makes our logic harder to test since it can’t be easily mocked or executed with the rest of our application-level tests.
I ended up writing integration tests on the SQL queries. They were slower than the unit tests I had before but 1.5 seconds per test vs. 0.1 second per test was a price I was pretty happy to pay.
In general I would prefer to keep domain logic all in one place but practicality trumps ideology.
- nomel 3y agoYeah, I'm having trouble understanding this. This sentence is very confusing to me: > While this gives you more flexibility, the tricky detail is that filtering happens only after your data is fetched. This is not different from fetching the results and filtering them inside your application. It just saves you some keystrokes. > It just saves you some keystrokes. No, it saves transferring tens of gigabytes to my application. I assume I'm missing something here, or maybe my data is different.
- Shorel 3y agoAgree. This was written by someone writing code so inefficient, I would never want them to be near my code.