All our datetime columns end with _at as an implicit convention, except one on the users table called last_emailed_timestamp. I made a PR to rename it to last_emailed_at.
I spend the time looking into a query detector for Laravel and chose to try out the one from BeyondCode. I tried modifying one of the output classes to make it work when running unit tests.
I found some candidates but didn’t have enough time to actually fix them But now I know a tool to use when detecting N+1 issues.
I realized a table existed for a long-gone feature. Removed it, and made the accessors of the table no-op to ensure no breakages (in case some old client havent updated).
Luckily we’re in the middle of reworking some of our database and persistence methods. We identified tables no longer used and are actively working towards slimming that down this and next week.
We had bullet gem included, but somehow it was not used (maybe because of historical reasons). So I enabled it and fixed some (n+1)'s.
Also it’s possible to integrate it into CI: enable in test environment and write to logs.
Found lots of missing foreign keys and column types discrepancies (bigint in foreign key and int key in the referenced table, sometimes the other way around)
Fixed
This topic came at the best moment - we were about to review db structures today anyway.
Thanks for naming the problem of N+1 - we have already met this problem in past. Unfortunately, in Python world there is only one library nplusone package and it seems rather obsolete.
Anyway, we know, that simply logging db queries might give a hint.
At the same time I have found, our project cold benefit from little automation so I followed the advice from day 19 and ended up with (invoke based) tooling:
$ inv --list
Available tasks:
db.dump Dump docker db to stdout (using internal container pg_dump binary)
db.logs See logs from dev db in docker
db.start Start dev db using docker-compose
db.status Show status of dev db using docker-compose
db.stop Stop dev db using docker-compose
My project has a schema-less MongoDB store, but I could remove some deprecated keys from a “messages” collection. Note the multi switch to remove them from all documents, not just the first one found:
Last week we found an unused column and today I sent a migration to remove this column the column used to handle if a record was already processed but we made a big refactor for that business logic last year.
I looked through the schema in one of our projects that has 9 tables. We’ve been pretty good with this project so I wanted to use this as a baseline for when we take a look at other projects over the next few months. I noticed that this project was missing the Bullet gem. I installed it and all the tests pass without exception