Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Two Month Debugging Story

kev.inburke.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: A Two Month Debugging Story

#11

Post by kevinburke »

rraval wrote: post #8

> To ensure each test has a clean slate, we clear the database between each test. The proposed solution to manually nuke the database state seems crazy to me. Some alternatives: 1. Run the entire test in a transaction, do flushes and assert as normal. At the end, ROLLBACK instead of COMMIT and now you have a pristine database again. [1] 2. Setup pristine DB state once and then use `CREATE DATABASE ... WITH TEMPLATE .…

Hi, I wrote the post. We'd love to use transactions but our ORM doesn't support it. More info here: https://kev.inburke.com/kevin/dont-use-sails-or-waterline/

We wrote our own transaction library and have been shifting queries over to it/a saner ORM. https://github.com/shyp/pg-transactions.

I've never heard of database templates, I'll have to take a look.

Re: A Two Month Debugging Story

#12

Post by kevinburke »

loftsy wrote: post #9

I think best practice here is to run the whole test in a transaction and then roll back the transaction at the end. This is the approach Django uses.

We'd love to do this but our ORM doesn't support it. https://kev.inburke.com/kevin/dont-use-sails-or-waterline/

Re: A Two Month Debugging Story

#13

Post by kevinburke »

utternerd wrote: post #5

disabled autovacuum by default I realize this wasn't their solution, but it's worth noting that generally speaking, disabling auto-vacuum isn't recommended. Even if you do, it will still force vacuum jobs to prevent transaction ID wraparound. * https://www.postgresql.org/docs/9.5/static/routine-vacuuming...

Agreed, but if you are running a CI provider and recycling containers, seems easy enough to do it as part of the recycle step.

Re: A Two Month Debugging Story

#15

Post by kevinburke »

gerbilly wrote: post #14

With Hibernate we used to connect it to a in memory DB just for the tests and to a real DB for production. It was easy and quick to drop schemas.

I agree that would be faster, but we rely a lot on Postgres's database constraints and we've previously had code problems go undiagnosed when the test schema didn't match production. Six in one, half a dozen in the other, I guess.

Re: A Two Month Debugging Story

#16

Post by utternerd »

kevinburke wrote: post #13
utternerd wrote: post #5

disabled autovacuum by default I realize this wasn't their solution, but it's worth noting that generally speaking, disabling auto-vacuum isn't recommended. Even if you do, it will still force vacuum jobs to prevent transaction ID wraparound. * https://www.postgresql.org/docs/9.5/static/routine-vacuuming...

Agreed, but if you are running a CI provider and recycling containers, seems easy enough to do it as part of the recycle step.

I agree it'd be a nice option for them to provide, but I don't believe making it the default for every customer is a laudable goal.

If vacuums are hanging/causing locks and these truly are just test tables, it might be beneficial to use temporary tables instead as the autovacuum daemon ignores them. Additionally, unlogged tables that reside on a memory disk can be insanely fast - might cut some additional time down depending on your data.

Re: A Two Month Debugging Story

#18

Post by agf »

kevinburke wrote: post #11
rraval wrote: post #8

> To ensure each test has a clean slate, we clear the database between each test. The proposed solution to manually nuke the database state seems crazy to me. Some alternatives: 1. Run the entire test in a transaction, do flushes and assert as normal. At the end, ROLLBACK instead of COMMIT and now you have a pristine database again. [1] 2. Setup pristine DB state once and then use `CREATE DATABASE ... WITH TEMPLATE .…

Hi, I wrote the post. We'd love to use transactions but our ORM doesn't support it. More info here: https://kev.inburke.com/kevin/dont-use-sails-or-waterline/ We wrote our own transaction library and have been shifting queries over to it/a saner ORM. https://github.com/shyp/pg-transactions . I've never heard of database templates, I'll have to take a look.

If your ORM doesn't know about transactions, that doesn't necessarily prevent you from wrapping your test runs in transactions. I was in a situation where I needed to start / rollback a transaction without ActiveRecord knowing about it, and was able to hack AR slightly to make that work -- so you can likely do the same.

You even mention in the Waterline section of that blog post that you've written your own transaction library, so this shouldn't be too hard.

Re: A Two Month Debugging Story

#20

Post by agumonkey »

mattbee wrote: post #2

Oof - seems like you're running on a managed platform that can't be debugged in a reasonable level of detail? If it were me I'd want to take the problem somewhere I _could_ get root access and debug it properly. So I'd be interested to know what value this (unnamed) CI platform provides to make it worth a wild goose chase.

The importance of having tools that allows to gather information when you need them.
Post reply on HN